Open Stack

Hey folks,

some update on proactive backporting for neutron, and a call for action  
from subteam leaders.

As you probably know, lately we started to backport a lot of bug fixes in  
latest stable branch (liberty atm) + became more systematic in getting  
High+ bug fixes into older stable branch (kilo atm).

I work on some tooling lately to get the process a bit more straight:

https://review.openstack.org/#/q/project:openstack-infra/release-tools+owner:%22Ihar+Hrachyshka+%253Cihrachys%2540redhat.com%253E%22

I am at the point where I can issue a single command and get the list of  
bugs fixed in master since previous check, with Wishlist bugs filtered out  
[since those are not applicable for backporting]. The pipeline looks like:

./bugs-fixed-since.py neutron <prevhash> |  
./lp-filter-bugs-by-importance.py --importance=Wishlist neutron |  
./get-lp-links.py

For Kilo, we probably also need to add another filter for Low impact bugs:

./lp-filter-bugs-by-importance.py --importance=Low neutron

There are more ideas on how to automate the process (specifically, kilo  
backports should probably be postponed till Liberty patches land and be  
handled in a separate workflow pipeline since old-stable criteria are  
different; also, the pipeline should fully automate ‘easy' backport  
proposals, doing cherry-pick and PS upload for the caller).

However we generate the list of backport candidates, in the end the bug  
list is briefly triaged and categorized and put into the etherpad:

https://etherpad.openstack.org/p/stable-bug-candidates-from-master

I backport some fixes that are easy to cherry-pick myself. (easy == with a  
press of a button in gerrit UI)

Still, we have a lot of backport candidates that require special attention  
in the etherpad.

I ask folks that cover specific topics in our community (f.e. Assaf for  
testing; Carl and Oleg for DVR/L3; John for IPAM; etc.) to look at the  
current list, book some patches for your subteams to backport, and make  
sure the fixes land in stable.

Note that the process generates a lot of traffic on stable branches, and  
that’s why we want more frequent releases. We can’t achieve that on kilo  
since kilo stable is still in the integrated release mode, but starting  
from Liberty we should release more often. It’s on my todo to document  
release process in neutron devref.

For your reference, it’s just a matter of calling inside openstack/releases  
repo:

./tools/new_release.sh liberty neutron bugfix

FYI I just posted a new Liberty release patch at:  
https://review.openstack.org/296608

Thanks for attention,

Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>
>> Rossella Sblendido <rsblendido at suse.com> wrote:
>>
>>> Hi,
>>>
>>> thanks Ihar for the etherpad and for raising this point.
>>> .
>>>
>>>
>>> On 12/18/2015 06:18 PM, Ihar Hrachyshka wrote:
>>>> Hi all,
>>>>
>>>> just wanted to note that the etherpad page [1] with backport candidates
>>>> has a lot of work for those who have cycles for backporting relevant
>>>> pieces to Liberty (and Kilo for High+ bugs), so please take some on your
>>>> plate and propose backports, then clean up from the page. And please
>>>> don’t hesitate to check the page for more worthy patches in the future.
>>>>
>>>> It can’t be a one man army if we want to run the initiative in long  
>>>> term.
>>>
>>> I completely agree, it can't be one man army.
>>> I was thinking that maybe we can be even more proactive.
>>> How about adding as requirement for a bug fix to be merged to have the  
>>> backport to relevant branches? I think that could help
>>
>> I don’t think it will work. First, not everyone should be required to  
>> care about stable branches. It’s my belief that we should avoid formal  
>> requirements that mechanically offload burden from stable team to those  
>> who can’t possible care less about master.
>
> Of course I meant ‘about stable branches’.
>
> 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