Open Stack

On 03/23/2016 05:52 PM, Ihar Hrachyshka wrote:
> 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).

Wow, great work, thanks a lot!

> 
> 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.

I've gone through the L2 and ML2 section. I backported missing patches
and added comments where I think no backport is needed.

cheers,

Rossella

> 
> 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
> 
> 
> __________________________________________________________________________
> 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