On Wed, Mar 1, 2017 at 11:37 PM, Shyam <srangana@xxxxxxxxxx> wrote:
Hi,
Our current back porting guidelines requests us to retain the "Change-ID" as generated for the commit in master. See [1]
I see that this is not followed consistently for all back ports.
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.
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] .
Having said that, I'd still like to get this in, so +1.
[1] https://paste.fedoraproject.org/paste/d6IkBv9RE1Q8lG~C~GfMg15M1UNdIGYhyRLivL9gydE=
[1] https://paste.fedoraproject.org/paste/d6IkBv9RE1Q8lG~C~GfMg15M1UNdIGYhyRLivL9gydE=
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.
So, here is what is proposed to help adhere to the back porting guidelines,
- 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,
- if yes, then it adds a comment on the commit appropriately
- if no, then it adds a comment stating this maybe incorrect
- 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)
- 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
We would like your feedback on this change.
We will wait until 7th March, 2017, for any feedback, based on which we will take this live!
Shyam
[1] Gluster back porting guidelines: http://gluster.readthedocs.io/en/latest/Developer-guide/Back port-Guidelines/
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
~ Atin (atinm)
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
