Open Stack

On Sun, Jun 2, 2013 at 7:50 PM, Tom Fifield <tom at openstack.org> wrote:

> On 02/06/13 11:40, Lorin Hochstein wrote:
>
>> 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).
>>
>> 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?
>>
>
>
> The automation sounds like an excellent idea. As it is, I'm a terrible
> offender of not backporting, so I would be very happy to have an easier way
> to do so.
>
> Regarding having a "default fail" scenario, I believe this should be a
> second step. The first step should be education of people so they put it in
> and think about what it means, rather than just putting in something to
> make the error go away - or worse, getting scared off and abandoning the
> patch :)
>
> Once we've got some basis of contributors doing things the right way, then
> it should be easy enough to enable "default fail" :)
>
> Thoughts?
>
>
Yeah, good idea. We can configure it as "non-voting", so jenkins will
report if the string is missing, but it won't vote -1 if the check fails.

Lorin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130602/69173e71/attachment.html>