On 03/01/2017 02:49 PM, Jeff Darcy wrote:
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
So the Jenkins job comes in later, we start with rfc.sh, which did not involve any URL fetching or parsing (at present).
It seems like there are multiple kinds of automation we could apply here. For example, if a backport commit contains a link to the Gerrit page for the original patch on master, then a script could use that to propagate the change ID before the patch is ever pushed. Taking that two steps further, we can get from the BZ# of a cloned bug to the BZ# of the original, and from there to the Gerrit page. The workflow could look like this:
Yes a lot of this is possible, there are some gotchas as well, but not getting into that at the moment, that can be ironed out in the implementation.
I would like to park this for now, and see how things change for backports when we move to a more github centered model.
Clone the bug gluster-backport $cloned_bug_id # script finds the cloned BZ # script finds the original BZ # script finds the original Gerrit page # script cherry-picks the original commit # script amends HEAD to have the right change ID It doesn't hurt to have a check after the fact as well, but if we need to develop the URL-fetching and page-parsing code to enforce a rule then we should use the same code to make following the rule easier as well.
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
