On Wed, Mar 01, 2017 at 01:07:50PM -0500, Shyam 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. > > 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) I think that doing this in a Jenkins job is too late for the majority of the cases. Modifying the Change-Id after it has been posted to Gerrit, it will be seen as a new change, and the previous one with the wrong Change-Id needs to be abandoned. Reporting it in a comment detected by Jenkins would be ok. But it would help much more to have this check and warning given by ./rfc.sh (or other commit hook to make it more portable). > - 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. In addition to this, we might want to extend this check with returning warnings when backports do not match the criteria that is mentioned in http://lists.gluster.org/pipermail/maintainers/2016-May/000706.html Thanks, Niels > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
