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

[Shyam]

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