[openstack-dev] [neutron][stable] proactive backporting

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri Oct 16 21:23:57 UTC 2015

It would also help if the process could split out bug fixes from unit tests. I had a bug fix get stuck while the unit tests were bikesheded for a while, and then the delay of not getting quickly backported to the stable branches then kicked in. All the while I had to patch production clouds by hand with a non upstreamed fix. I'm all for having unit tests to ensure the bugs don't creep back in, but regression bugs should be fixed as quickly as possible.

From: Edgar Magana [edgar.magana at workday.com]
Sent: Friday, October 16, 2015 2:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][stable] proactive backporting

+ 2 and total support for it.

Looking forward to reviewing the first set of them.


On 10/16/15, 5: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:
>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,
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list