Last updated 28 June 2011.

What is a patch review sprint?

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!

How It Works

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. :)

There are more tips on performing patch reviews at Reviewing patches part of the larger Help in testing code part of the handbook.


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 --help you 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.

Patch review cheatsheet

Note: The Version control tab always has the most up-to-date recommended instructions.

  1. Download a copy of Drupal core from Git. You only need to do this once:
    git clone --branch 8.x
  2. Find an issue that needs review from the "Drupal" project issue queue.
  3. 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.
  4. 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 wget:
    cd /path/to/htdocs/drupal
  5. Apply the patch, using Git:
    git apply -v example.patch

    See Troubleshooting 'git clone' if you receive errors during this step.

  6. 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.
  7. If you run into a bug, see if the same bug exists if you revert the patch:
    git apply -R example.patch
  8. Post your results to the issue, as described above in "How it works."
  9. Now, get back to a "clean" copy of Drupal and go back to step 2!
    git reset --hard


dww’s picture

Instead of links like this:[0]=156281&status[...

that hard-code the nid for the 7.x-dev release node, please use links like this:[0]=7.x&status[0]=...

Then, the links will always work right, even once alphas or betas or rcs are being tagged, or once we start making release nodes for the unstable releases, or whatever...

See #383356: Fix core-related issue counts and links to use the version=7.x views filter for a related request (to fix the "Contributor links" block from drupalorg.module), and #97569: allow filtering issue queue by "series" for the issue where I added this happy cool new feature. views2 + project_issue = yay! ;)


p.s. Yes, I know I could just silently edit the page to fix this myself, but by posting a comment, I'm hoping to raise awareness of folks making other pages like this in the future.

My professional services are available through 3281d Consulting