4

How do I request that LTS include a particular bug fix?

The issue in question is https://issues.civicrm.org/jira/browse/CRM-13287. It's an issue for my site upgrading to 4.4 now and presumably 4.6 once it's officially the LTS release, so I'd like to get it incorporated.

I can run a patch for the simple fix as described in the jira, it's just the deletion of a single space changing $nullIndex = $nullValueIndex = ' '; to $nullIndex = $nullValueIndex = '';

But once I have the patch, what do I do with it to get it applied to LTS?

5

The process to get a bug fix included is to submit a Pull Request ("PR") to that branch on Github.

This is documented in the civicrm wiki: How to Submit a Patch to a Version Branch

  1. Get yourself a GitHub account.
  2. Create an issue in JIRA (already done, CRM-13287).
  3. Create a fork of the appropriate branch of civicrm-core to your own account.
    • At this point I'd usually create a branch named for the JIRA issue.
  4. Make changes to your forked repository.
    • For this small change you could easily apply the patch manually in the GitHub web UI, but for most changes you would clone the codebase to your computer using Git / GitHub app, change the code locally and test it, then push the changes back to your fork.
  5. Use the GitHub web UI to submit a Pull Request back to the original branch.
  6. Note the PR number / URL in GitHub, go back to the JIRA issue and add a comment identifying the the PR in the issue.

To get a change into LTS, submit your change to the appropriate version branch - currently 4.4 - as well as to the master branch.


Going further ... Your aim is to make it easy for maintainers to accept the change, to make it clear why they should accept the change, and to reassure them that the change is not harmful. Submitting a PR addresses the first of these.

The PR makes it easy for maintainers to merge the changed code in. To help illustrate the motivation for accepting the change, you might need to improve the ticket in JIRA so that the severity of the problem is clear. To demonstrate that the change is not harmful, you might expand test coverage to prove that the functionality before and after the change is equivalent or even improved.

  • Thanks. Done. Hopefully something approximating correctly. Just noting here that I am doing only 4.4. Code for latest version looks to be different. Perhaps this is fixed already? I don't have capacity to test right now. - – Anne Savage Oct 5 '15 at 17:55
  • Great! Hmm ... Up to maintainers but I suspect they might not want to diverge 4.4 and master. Instead you might consider submitting the appropriate change (whatever addressed this in 4.6) as a PR to LTS. Or it may just be that the code in question was relocated. Or you could upgrade to 4.6 which might be less scary :) – Chris Burgess Oct 5 '15 at 18:07
  • @AnneSavage I recommend (1) checking you've linked the PR back to JIRA, and (2) marking your question answered if appropriate. – Chris Burgess Oct 6 '15 at 1:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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