<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 1, 2017 at 11:37 PM, Shyam <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Our current back porting guidelines requests us to retain the "Change-ID" as generated for the commit in master. See [1]<br>
<br>
I see that this is not followed consistently for all back ports.<br>
<br>
The advantage of having the same Change-ID across back ports to branches and master, is that it gives us a master key, to track automatically, if a back port has reached all relevant branches.<br></blockquote><div><br></div><div>We do have a tool written by Prasanna which can fetch out details like which patch from master hasn't been backported to a particular branch. refer [1] .<br><br></div><div>Having said that, I'd still like to get this in, so +1.<br><br>[1] <a href="https://paste.fedoraproject.org/paste/d6IkBv9RE1Q8lG~C~GfMg15M1UNdIGYhyRLivL9gydE=">https://paste.fedoraproject.org/paste/d6IkBv9RE1Q8lG~C~GfMg15M1UNdIGYhyRLivL9gydE=</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For example, during the stabilization phase of a release, if a commit is made to master, and then back ported to an older STM/LTM, it should also reach the current release under stabilization. Auditing this is very manual and time consuming when Change-ID's differ.<br>
<br>
So, here is what is proposed to help adhere to the back porting guidelines,<br>
- We will run an Jenkins job for patches posted against non-master branches, that validates if the change-ID in the commit is present in master,<br>
- if yes, then it adds a comment on the commit appropriately<br>
- if no, then it adds a comment stating this maybe incorrect<br>
<br>
- The Jenkins job will *not* vote, it is to serve as a helpful reminder to committers and to maintainers, to either request for the correct change-ID, or in the *rare* circumstance that this is not a back port and is a branch specific change, proceed with the merge (as appropriate)<br>
<br>
- Finally, we discourage squashing multiple changes into one commit when back porting, so that the above is retained, this will be left as a best practice to follow<br>
<br>
We would like your feedback on this change.<br>
<br>
We will wait until 7th March, 2017, for any feedback, based on which we will take this live!<br>
<br>
Shyam<br>
<br>
[1] Gluster back porting guidelines: <a href="http://gluster.readthedocs.io/en/latest/Developer-guide/Backport-Guidelines/" rel="noreferrer" target="_blank">http://gluster.readthedocs.io/<wbr>en/latest/Developer-guide/Back<wbr>port-Guidelines/</a><br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div><div>~ Atin (atinm)<br></div></div></div></div>
</div></div>