Answers.Body: <p>The process to get a bug fix included is to <strong>submit a Pull Request ("PR") to that branch on Github</strong>.</p>
  
  <p>This is documented in the civicrm wiki: <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/GitHub+for+CiviCRM#GitHubforCiviCRM-How-To:SubmitaPatchtoaVersionBranch">How to Submit a Patch to a Version Branch</a></p>
  
  <ol>
  <li><a href="https://github.com/join">Get yourself a GitHub account</a>.</li>
  <li>Create an issue in JIRA (already done, <code>CRM-13287</code>).</li>
  <li>Create a fork of the appropriate branch of <code>civicrm-core</code> to your own account.
  
  <ul>
  <li><em>At this point I'd usually create a branch named for the JIRA issue.</em></li>
  </ul></li>
  <li>Make changes to your forked repository. 
  
  <ul>
  <li><em>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.</em></li>
  </ul></li>
  <li>Use the GitHub web UI to submit a Pull Request back to the original branch.</li>
  <li>Note the PR number / URL in GitHub, go back to the JIRA issue and add a comment identifying the the PR in the issue.</li>
  </ol>
  
  <p>To get a change into LTS, submit your change to the appropriate version branch - currently 4.4 - as well as to the master branch.</p>
  
  <hr>
  
  <p><strong>Going further</strong> ... 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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-05T17:55:30.283Z
Answers.Text: 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. -
Answers.UserDisplayName: ASav
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-05T18:07:19.543Z
Answers.Text: 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 :)
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-06T01:35:25.223Z
Answers.Text: @AnneSavage I recommend (1) checking you've linked the PR back to JIRA, and (2) marking your question answered if appropriate.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-05T17:30:59.323Z
Answers.LastActivityDate: 2015-10-05T17:50:32.520Z
Answers.LastEditDate: 2015-10-05T17:50:32.520Z
Answers.UserDisplayName: Chris Burgess
Body: <p>How do I request that LTS include a particular bug fix? </p>
  
  <p>The issue in question is <a href="https://issues.civicrm.org/jira/browse/CRM-13287" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-13287</a>.  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.</p>
  
  <p>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 = '';</p>
  
  <p>But once I have the patch, what do I do with it to get it applied to LTS?</p>
  
Tags: <custom-fields><lts>
Title: How to request bug fix for LTS
ThreadText: # How to request bug fix for LTS
  
  (Asked by: username_0 on 2015-10-05)
  
  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?
  
  **Tags:** custom-fields, lts
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-10-05. Score: 5 | Accepted answer
  
  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](http://wiki.civicrm.org/confluence/display/CRMDOC/GitHub+for+CiviCRM#GitHubforCiviCRM-How-To:SubmitaPatchtoaVersionBranch)
  
  1. [Get yourself a GitHub account](https://github.com/join).
  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.
  
  > **Comments:**
  > **username_0**: 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. -  
  > **username_1**: 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 :)  
  > **username_1**: @AnneSavage I recommend (1) checking you've linked the PR back to JIRA, and (2) marking your question answered if appropriate.  
  
  ---
  
  