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

[Shyam]

On 03/01/2017 01:33 PM, Atin Mukherjee wrote:
>
>
> On Wed, Mar 1, 2017 at 11:37 PM, Shyam <srangana at redhat.com
> <mailto:srangana at redhat.com>> 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 at gluster.org <mailto:Gluster-devel at gluster.org>
>     http://lists.gluster.org/mailman/listinfo/gluster-devel
>     <http://lists.gluster.org/mailman/listinfo/gluster-devel>
>
>
>
>
> --
>
> ~ Atin (atinm)