Open Stack

This sounds like a pretty decent idea to me. Considering Neutron's patch
merge rate this activity should hopefully not take a consistent chunk of
your Friday.
It might also make sense to ask contributors to resume the habit of tagging
bugs with 'backport-potential' even if not in the RC period.

I am glad to offer my help as well in evaluating "backport worthiness", and
the process you outlined looks very good to me.
If there's any discussion needed for assessing whether a bug fix should be
backported or not, we could either use the etherpad or launchpad, with a
slight preference for launchpad.

Salvatore

On 16 October 2015 at 16:19, Kyle Mestery <mestery at mestery.com> wrote:

> On Fri, Oct 16, 2015 at 7:33 AM, Ihar Hrachyshka <ihrachys at redhat.com>
> wrote:
>
>> Hi all,
>>
>> I’d like to introduce a new initiative around stable branches for neutron
>> official projects (neutron, neutron-*aas, python-neutronclient) that is
>> intended to straighten our backporting process and make us more proactive
>> in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a
>> known bug hits a user that consumes stable branches, but backport fixes in
>> advance quickly after they hit master.
>>
>> The idea is simple: every Fri I walk thru the new commits merged into
>> master since last check; produce lists of bugs that are mentioned in
>> Related-Bug/Closes-Bug; paste them into:
>>
>> https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>>
>> Then I click thru the bug report links to determine whether it’s worth a
>> backport and briefly classify them. If I have cycles, I also request
>> backports where it’s easy (== a mere 'Cherry-Pick to' button click).
>>
>> After that, those interested in maintaining neutron stable branches can
>> take those bugs one by one and handle them, which means: checking where it
>> really applies for backport; creating backport reviews (solving conflicts,
>> making tests pass). After it’s up for review for all branches affected and
>> applicable, the bug is removed from the list.
>>
>> I started on that path two weeks ago, doing initial swipe thru all
>> commits starting from stable/liberty spin off. If enough participants join
>> the process, we may think of going back into git history to backport
>> interesting fixes from stable/liberty into stable/kilo.
>>
>> Don’t hesitate to ask about details of the process, and happy backporting,
>>
>> Wow, this is a great idea Ihar! Thanks for taking this on! Count me in on
> helping with this effort as well.
>
> Thanks,
> Kyle
>
>
>> Ihar
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151016/844c3a0e/attachment.html>