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