Last updated June 28, 2011.
A patch review sprint is getting people together for a set amount of time – anywhere from a couple of hours to a couple of days – and just reviewing patches (see what is a patch?).
Patch review sprints offer a great learning experience, as they help expose people to many parts of Drupal they may not otherwise have had access to. It's also a lot of fun, as it gets folks talking and working directly with Drupal core contributors and having a rompin' stompin' good time making Drupal better!
This document describes how patch reviews work, the list of prerequisites you need in place in order to help, and a helpful cheat-sheet of commands for use while patch reviewing. Please note that "coding skills" is not on the list of prerequisites. While people with coding skills can perform certain types of reviews better than non-coders, non-coders can also perform certain types of reviews better than coders. In short: everyone is welcome!
The goal is to try and knock the core patches to review queue down to zero (or as close to it as possible). Choose an issue from the list that seems interesting, and apply the patch to test it out. If you're looking for a patch to review in a specific area of interest, you can also limit the list by component (such as "markup" or "documentation") or glance through the Drupal core community initiatives pages for specific topical areas. Also, the "novice" issue queue contains issues that only change minor things and should be fairly easy to review if you're just getting your feet wet.
As a patch reviewer, your primary objective is to find a reason to mark a patch "needs work." Some reasons for doing so include:
- The patch has grammar or spelling mistakes.
- The patch does not work when viewed in browsers such as Safari, IE, or Opera.
- The patch causes errors when applied to your copy of Drupal.
- When trying something crafty to out-smart the original patch author, you come across unintended behaviour.
- The resulting user interface is obtuse and difficult to use.
- The code doesn't conform to coding standards.
- The changes are insufficiently documented and/or difficult to understand.
- The patch does not contain tests to prove a new feature works, and/or a bug stays fixed.
If, and only if, you can find nothing wrong with the patch after trying really hard to do so, then you mark it "reviewed & tested by the community."
Regardless of the outcome of the patch review, document carefully in your reply all of the things you tried and what results you achieved, things you liked about the patch, things you did not like, and so on. A good, solid patch review is typically 2-3 paragraphs or several bullet points. "+1" is NOT a patch review.
Remember to make sure that your comment reflects any conversation that might've happened in IRC, in a conversation over lunch, etc. If it's not in the issue queue, it never happened. :)
In order to participate in a patch review sprint, you'll need the following:
- An inquisitive mind with an attention to detail. Extra bonus if you are one of those people with an uncanny ability to break things.
- A development environment running at least PHP 5.2. An easy way to get this is to install a local Apache/MySQL/PHP package such as XAMPP. There are helpful videos for Windows, Mac, and Ubuntu Linux
- Git. If you go to the command line and type in
git --helpyou should see a bunch of text. If you do not, and instead see something like "Command not found," you need to download and install it.
Note: The Version control tab always has the most up-to-date recommended instructions.
- Download a copy of Drupal core from Git. You only need to do this once:
git clone --branch 8.x http://git.drupal.org/project/drupal.git
- Find an issue that needs review from the "Drupal" project issue queue.
- Give a quick read through the patch (even if you're a non-coder) and look for anything obviously wrong that sticks out to you.
- From the issue, download the patch file to the "root" of your local Drupal installation (the folder with index.php in it). You can either do this with your browser or from the command line with a tool like
cd /path/to/htdocs/drupal wget http://drupal.org/files/issues/example.patch
- Apply the patch, using Git:
git apply -v example.patch
See Troubleshooting 'git clone' if you receive errors during this step.
- Click around your Drupal interface and try and break the patch. Try and think of things that the original author may not have intended; for example, testing OpenID on a patch that affects the user registration form.
- If you run into a bug, see if the same bug exists if you revert the patch:
git apply -R example.patch
- Post your results to the issue, as described above in "How it works."
- Now, get back to a "clean" copy of Drupal and go back to step 2!
git reset --hard