Open Stack

On Mon, Jun 3, 2013 at 9:33 AM, Anne Gentle
<annegentle at justwriteclick.com>wrote:

>
>
>
> On Mon, Jun 3, 2013 at 8:31 AM, Lorin Hochstein <lorin at nimbisservices.com>wrote:
>
>>
>> On Sun, Jun 2, 2013 at 11:09 PM, Anne Gentle <
>> annegentle at justwriteclick.com> wrote:
>>
>>>
>>>
>>>
>>> On Sat, Jun 1, 2013 at 8:40 PM, Lorin Hochstein <
>>> lorin at nimbisservices.com> wrote:
>>>
>>>> All:
>>>>
>>>> I've noticed that there have been several bugs in the grizzly branch
>>>> that were fixed in the master but hadn't been backported to stable/grizzly.
>>>> I'd like to propose the following automated approach to ensure backports
>>>> happen more regularly:
>>>>
>>>> Any patch to the master branch must specify in the commit message
>>>> whether the patch should be backported. For example:
>>>>
>>>> backport: stable/grizzly
>>>>
>>>> or
>>>>
>>>> backport: none
>>>>
>>>> or
>>>>
>>>> backport: stable/grizzly stable/folsom
>>>>
>>>>
>>>> If this line is missing from the commit log, then a gating job will
>>>> fail, and jenkins will link to the error message (e.g., "Missing 'backport:
>>>> ' line. Please specify "backport: stable/grizzly" if this should be
>>>> backported to grizzly or "backport: none" if this shouldn't be backported).
>>>>
>>>>
>>> This sounds like a good mechanism, and I love automation. For how many
>>> more weeks / months will the automation work without any merging
>>> intervention needed manually? I haven't had too much trouble but imagine as
>>> more patches get backported it'll get worse? What do you think?
>>>
>>>
>> I'm having a little trouble understanding the question. Are you asking
>> how long I think that the automation will work before it hits a patch that
>> can't automatically backport?
>>
>> I suspect that there will be a fairly large number of patches where
>> attempt to auto-backport will fail due to conflicts. I think when that
>> happens Jenkins will need to add a message to the master patch proposal
>> mentioning that the auto-backport failed. At that point, somebody from the
>> doc team will need to manually resolve the change and do the backport.
>>
>>
> Yep, you answered my question. So what's the process after Jenkins can't
> auto-backport? Just git review -d the patch and manually resolve,
> repatching?
>
>
I think if Jenkins can't auto-backport, there won't be a new,
auto-generated patch against stable/grizzly. Assuming when the script runs
the cherry-pick, that it fails because of a conflict, there really isn't
anything the script can do at that point to recover. All it can do is post
a message against the original patch saying "auto-backport failed".

So, if the auto-backport fails, the process degenerates back to what we do
currently. Somebody will have to notice the "auto-backport failed" message,
manually create a new branch off of stable/grizzly, cherry-pick from the
patch against the master branch, and submit that.

Lorin




> Anne
>
>
>> Or, were you asking about something else?
>>
>> Lorin
>>
>>
>>
>>> Anne
>>>
>>>
>>>> When the patch is merged into trunk, then jenkins automatically does a
>>>> cherry-pick and merge proposal against the branches specified in the
>>>> backport line.
>>>>
>>>>
>>>> What do you folks think?
>>>>
>>>>
>>>> Lorin
>>>>
>>>> --
>>>> Lorin Hochstein
>>>> Lead Architect - Cloud Services
>>>> Nimbis Services, Inc.
>>>> www.nimbisservices.com
>>>>
>>>> _______________________________________________
>>>> Openstack-docs mailing list
>>>> Openstack-docs at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>>>>
>>>>
>>>
>>>
>>> --
>>> Anne Gentle
>>> annegentle at justwriteclick.com
>>>
>>
>>
>>
>> --
>> Lorin Hochstein
>> Lead Architect - Cloud Services
>> Nimbis Services, Inc.
>> www.nimbisservices.com
>>
>
>
>
> --
> Anne Gentle
> annegentle at justwriteclick.com
>



-- 
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130603/94f075ac/attachment-0001.html>