On 03/01/2017 01:33 PM, Atin Mukherjee wrote:
On Wed, Mar 1, 2017 at 11:37 PM, Shyam <srangana@xxxxxxxxxx <mailto: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] .
I have used this tool in the recent past (unable to find the source now). I think it still lacks a unique key, and relies on commit message similarity (if I am not wrong). We want to eliminate any noise/false positives here, and rely on a proper key, hence this approach.
This is not to state the tool is bad (it works in the current scheme of affairs), but that we want better certainty.
Having said that, I'd still like to get this in, so +1. [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/Backport-Guidelines/ <http://gluster.readthedocs.io/en/latest/Developer-guide/Backport-Guidelines/> _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx <mailto:Gluster-devel@xxxxxxxxxxx> http://lists.gluster.org/mailman/listinfo/gluster-devel <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
