> 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 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: 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
