10

What is the proper process to contribute patches to Drupal core?

Let's say I find a bug in Drupal core, fix it, and create a patch. How do I submit it?

If the bug is in Drupal 7, do I have to also fix it in Drupal 8, and submit two patches? Does this also apply to documentation bugs/improvements?

Do all patches also require a unit test?

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

  • 3
    For the time being, I am looking for answers assuming that I already have an account on drupal.org, know how to use git, know how to check out core, and know how to create git patches. Once we have good answers, we can annotate or add an answer to outline this process. – mpdonadio Feb 2 '13 at 14:24
  • As this is a response to an issue a core maintainer raised at meta.drupal.stackexchange.com/questions/2325, the post notice will be enforced. We need a good summary of the process, particularly about the questions above. Answers that just link out to other pages will be downvoted and/or deleted. I am hoping this question will serve as a resource that we can point DA users to when they find a problem with core. – mpdonadio Feb 2 '13 at 16:53
6

If the bug is in Drupal 7, do I have to also fix it in Drupal 8, and submit two patches?

If the bug is present in the version being developed (in this case Drupal 8), and the previous version (Drupal 7), then the bug should be first fixed the currently developed version, and then on the previous version(s).

If the bug is not present in the latest developed version, for example because the bug is for a function that has been removed, or that has been already changed, then the patch should be provided for the version before the currently developed one.

The workflow that is followed is:

  • First the patch is created, and submitted for reviews, for the most recent version, even if still under development (such as in the case of Drupal 8)
  • Once that patch is applied to Drupal, a patch that applies for the previous version is created, and submitted for reviews

You can create patches for two Drupal versions at the same time, but since the patch for the latest Drupal version could require changes, it is better to work on the patch for the currently developed version, than working on two different patches that both require to be changed.

See also: Backport Policy.

Does this also apply to documentation bugs/improvements?

Yes, it does. Also in this case, if the currently developed version removed the function/method to which the documentation is referring, then the patch needs to be provided for the previous version.

Do all patches also require a unit test?

If the patch is for the documentation, it doesn't require tests. The test bot running on http://qa.drupal.org checks the Drupal code after the patch is applied; if the patch introduces syntax errors (for example because the comment is closed before the needed), then the test bot will report an error about the patch before tests are run.

If the patch is for a new feature, then the tests are required.

If the patch is to fix a bug, then the tests could be required from the maintainers, if there isn't already a test checking a specific feature. The test is generally necessary to avoid re-introducing the same bug when changing in future the same code. If the bug is merely a variable that is initialized, but never used from a function/method, then chances are the tests are not required.

  • Can the same issue contain patches for multiple core versions? – mpdonadio Feb 2 '13 at 19:37
  • 1
    If the issue applies to more than one version, it can contain patches for every interested version. – kiamlaluno Feb 2 '13 at 19:49
  • Is it always the case where the D8 patch is submitted first, then the D7 version? Or are there cases where submitting both at the same time are appropriate? – mpdonadio Feb 3 '13 at 14:19
  • You can submit patches for two different versions, but the patch that is first applies is for the most recent version. It is better to create first the patch for the more recent version, as the patch could require changes. – kiamlaluno Feb 3 '13 at 21:43
3

Every project page on drupal.org has a "Version control" tab at the top. It gives not only a great overview of all the code repository options for the specific project, all the git command examples are also tailored for the project. You can even interactively change it to a specific version too.

For Drupal core you find that page on http://drupal.org/project/drupal/git-instructions

Then when you have created your patch, you simply just attach the patch file to an issue that explains what you patch does.

Two important things to point out is to make sure the patch is ending with ".patch" and to set the status to "Needs review". This so that the testbot will notice it and automatically run its test.

New code always needs to be accompanied by tests.

Note that this is possible to turn off by projects and some do. For Drupal core it is on though so all patches will be tested.

You can find more at http://drupal.org/contribute/development .

  • This is a good start. – mpdonadio Feb 2 '13 at 17:34

protected by kiamlaluno Feb 20 '13 at 17:40

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.