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

[Shyam]

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.

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/Backport-Guidelines/