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

[Atin Mukherjee]

On Wed, Mar 1, 2017 at 11:37 PM, Shyam <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] .

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



-- 

~ Atin (atinm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170302/af09b906/attachment.html>