[Gluster-devel] Back porting guidelines: Change-ID consistency across branches

Shyam srangana at redhat.com
Wed Mar 1 18:07:50 UTC 2017


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.

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 
   - 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!


[1] Gluster back porting guidelines: 

More information about the Gluster-devel mailing list