From PostgreSQL wiki
Jump to navigationJump to search

Part UG meeting, part hackathon: it's the Patch Review Party, and it's coming to a city near you - because you're going to have one! Your goal is to introduce people to the patch review process, add them to the RRReviewers pool, and review some patches.

Stuff organizers (that's you!) need to do beforehand

Find some people to attend

Have people sign up in advance. PDXPUG limits ours to 10-12 people, usually due to space limitations.

Find a date & time

3 hours seems to be the sweet spot - 2 hours is too short, and 4 is too large a chunk out of people's days. Weeknights (Sun - Thurs) work best for our group.

Provide user support

  • beverages & food (potluck may be ok if you're doing it on the weekend)
  • carpool setup/parking/easy access to public transit
  • seating
  • easy restroom access
  • Internet access
  • have the latest Pg & the patches on a USB key (because there's usually one person who forgets to get them)
  • power
  • some way of sharing info, eg a whiteboard, etherpad, or your group's IRC channel. For our first PRP, some non-local Pg experts and the current commitfest manager volunteered to sit in our group's IRC channel & answer questions. This was a big help.

Last, notify attendees of the Stuff They Need to Do Beforehand (next section).

Stuff attendees need to do beforehand

Set up the current version of Pg

(this step alone saves a significant amount of time)

git clone git://

If it's been a few days since you cloned the repo, update it before the PRP with `git pull origin`.

configure && make && make check

Make sure you're doing this somewhere away from any other Pg installs you don't want to mess with.

Review the relevant docs on the wiki

Acquire patches

For our first PRP, we had the CommitFest Manager assign our group some easy patches to review. Now, we generally choose our own from the current list of patches for review from

Attendees can download their own patches (in advance if possible!), or the organizer can have them available by USB.

At the PRP

We've had good luck doing solo & paired reviewing. Pick whatever works best; our last PRP we had a mix & it worked fine. If it's your first one, you may want to pair people up beforehand, so you have new people working with more experienced people.

How to patch, if you've never done it before (old school):

patch -b -p0 < [patchfile]

Or, newer & easier with git:

git apply [patchfile]

...then run `configure && make check && make install` again.

Some tips:

  • You can do a "git branch" before you apply the patch, if you want to keep your changes separate. (git branch [branch_name])
  • Acquiring patches from Click the patch name, then the "Patch" link under comments to go to the -hackers mailing list, where you should find the patch as an attachment - make sure you get the most recent version.
  • Check first that the patch is in the right format
  • You may need to deal with Windows-style carriage returns; try:
    • dos2unix
    • perl -pi -e 's/\r\n/\n/;' [patchfile]
  • If you're using patch, you might need to:
    • alter the file paths at the top of the patch file to match what's in your git repo
    • adjust the patch level (the -p argument to the patch command)

Wrap-up & Followup

Don't worry if not everyone completes their review at the PRP; some patches are just too complex for one evening. At the first PRP, and maybe when you have new people, you may need to find out what the status of the reviews are & make sure everyone follows up properly. (This saves the CommitFest Manager from having to do that.)