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/
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
