[openstack-dev] [neutron][stable] proactive backporting
salv.orlando at gmail.com
Fri Oct 16 15:36:13 UTC 2015
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
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.
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>
>> 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:
>> 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.
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev