[Gluster-devel] Back porting guidelines: Change-ID consistency across branches
srangana at redhat.com
Wed Apr 5 21:03:33 UTC 2017
On 03/01/2017 02:20 PM, Niels de Vos wrote:
> On Wed, Mar 01, 2017 at 01:07:50PM -0500, Shyam wrote:
>> Our current back porting guidelines requests us to retain the "Change-ID" as
>> generated for the commit in master. See 
>> 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).
I posted change  to modify rfc.sh appropriately. It is not fool
proof, but combined with the future Jenkins job posting it's results we
should be able to keep this requirement in check.
>> - 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
>> We will wait until 7th March, 2017, for any feedback, based on which we will
>> take this live!
Dates are such funny things! :) joke is on me!
>>  Gluster back porting guidelines:
 Change posted: https://review.gluster.org/17004
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
More information about the Gluster-devel