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

[Shyam]

On 03/01/2017 02:20 PM, Niels de Vos wrote:
> 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).

Yes agreed.

I posted change [2] 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
> 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!

Dates are such funny things! :) joke is on me!

>>
>> Shyam
>>
>> [1] Gluster back porting guidelines:
>> http://gluster.readthedocs.io/en/latest/Developer-guide/Backport-Guidelines/

[2] Change posted: https://review.gluster.org/17004

>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel