For this Wednesday's Hack Night (18th), I'm going to demo my patch creation and review workflow, and there are some things you can bring or set up early to improve your experience. This should also apply to future hack nights as well.
At the start of the meeting (and later as needed), we can help people set up testing environments, but whatever you can do ahead of time will help.
1) Laptop
It will be difficult for you to get much done without one, but you might be able to pair up with someone.
2) Local Drupal 7 install
You will need a place to apply patches and test them on your laptop. MAMP / WAMP / XAMP / Acquia stack / etc. are recommended, but if you have a development server that is an OK plan B.
Install Drupal from CVS using the HEAD branch (not the development snapshots, actually check it out from CVS). If you have any other patches installed and in the process of testing, you may want to make 1+ extra Drupal installs so you have a clean environment.
3) Development Environment
Everyone will need CVS, so they can check out HEAD.
Anyone who wants to deal with code should have their favorite editor installed.
I recommend Eclipse, because it makes applying and creating patches very easy and has a great diff viewer. If you do install Eclipse, it helps to make the workspace and web roots the same folder or symlink workspace files into your web folders (I can demonstrate).
4) Modules
The only module you really need to enable in D7 for testing is simpletest, but admin_menu, devel, etc. can speed up the process.
Coder is very helpful for code style guidance, but it doesn't work in D7 directly yet. Install it on a D6 devel site, and then you can copy-paste the patch (or upload the file directly) to get the guidance in D7 as well. We can set something up for us to all share this, so setting up your own is a lower priority.
5) A Project
More than 2-4 people per project is going to get unwieldy, so try to find something interesting to work on. There are a bunch listed in this discussion: http://groups.drupal.org/node/33234
I'm going to be working on http://drupal.org/node/497804 personally.
Comments
If anyone wants to come to
If anyone wants to come to hack night who doesn't have a laptop, let us know ahead of time and we'll try to get an extra iMac set up for you.
I'm gonna come but...
I don't have a laptop right now, just my iMac which I'd rather not have to tote in there, so it'd be super cool if I could use one there. Eclipse is what I use for my IDE so if that's what the iMacs have (as per Kens tips) that'd awesome.
Adam A. Gregory
Drupal Developer and Consultant
Hire me
http://AdamAGregory.com
Twitter Me
http://twitter.com/adamgregory
For the CVS un-savvy, the
For the CVS un-savvy, the easiest way to checkout Drupal 7 from CVS is to follow these instructions:
cd /Applications/MAMP/htdocscvs -z6 -d :pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout drupalIf you have problems, more detailed instructions are here: http://drupal.org/node/133304
Dreditor
Dreditor is a Grease Monkey plugin that makes patch review a little easier.
It helps with code style and such review the most, since it lets you view a good diff and annotate it without installing it locally. So, it speeds up the part of the process before you actually need to see if it works as advertised (worthwhile if you review a lot, not a big deal if you don't).
Ken Winters
Meeting Notes
Notes from tonight: (now edited for extra details)
1) Finding something to work on
Deadlines are a big deal. If API freeze is in 2 weeks, most devs will be working on / reviewing API patches.
Priority lists like User Experience are often provided by the community or Dries
Issue filters like Critical or Novice Tag can also help find important or easy issues, or issues you might care more about.
The documentation teams always need help and those issues are usually easier to jump into - need to check out some modules for api.drupal.org behavior, Julia do you have the info?
If you don't want to work on core, there are plenty of module issues that need addressing.
2) Writing a patch
Testing / Coding Environment - walkthru d74 setup (MAMP, Eclipse, symlink in some folders from Eclipse to keep sites folder out of diff)
Check out the right code branch from CVS (HEAD for D7) - don't use the dev tarballs!
Coding Standards and Coder - following the coding standards is critical for core patches, less important for contrib
Writing simpletests - find a good example to work off of. basic concepts (drupal_execute, assertions, functions that take input and give simple output are easiest to test) - to debug, turn on verbose mode and use the verbose or debug function calls rather than watchdog
Running simpletests - D6 needs module, D7 it's in core.
Patch creation instructions
Read over your diff before you submit, look for anything that was included accidentally (whitespace, etc.) - avoid whitespace fixes in code you didn't have to modify
Provide the right patch format (unified) - makes it easier on the maintainers
3) Getting people to review your patch
Core: IRC - link to it in #drupal and offer a review trade
Modules - usually the maintainer will do it
4) Reviewing other people's patches
Don't RTBC unless you're fairly confident (works, is not evil, follows coding standards)
Also don't be too scared of RTBC, Webchick or Dries (and others) still carefully look over anything RTBC
If you point out simple bugs / code style issues, you can still cut down on work for the major core contributors (it will be closer to good when they get to it) so you don't have to handle things you don't understand
Ken Winters