Open Stack

On Wed, Mar 23, 2016 at 12:52 PM, Ihar Hrachyshka <ihrachys at redhat.com> 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

Kudos on the new tooling, this will make at least part of the process easier.

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

Ideally, proactive backporting will continue for a long time by being
self sufficient, and that means we get buy in from a sufficiently
large group of people in the Neutron community and obtain critical
mass. I think the incentive is there - Assuming you take part in
delivering OpenStack based on a stable branch, you want that branch as
bug-free as possible so that you don't have to put out fires as people
report them, rather you prevent issues before they happen. This is
much cheaper in the long run for everyone involved.

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