Open Stack

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.

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

Thanks in advance,
Ihar

Miguel Angel Ajo <mangelajo at redhat.com> wrote:

> I thought that may be, some of the work Ihar is proposing, could be  
> automated.
>
> Like, for example, checking if bug fixes are backportable as-is to the  
> previous stable
> branches, and if they pass testing.
>
> If that's the case, the bot could automatically automatically add the bug  
> to the list, or
> flag it with some sort of specific flag, so, we humans could verify it  
> does make sense
> to backport such bug, and if it actually meets the "backportable"  
> guidelines.
>
>
>
> Kuvaja, Erno wrote:
>>> -----Original Message-----
>>> From: Ihar Hrachyshka [mailto:ihrachys at redhat.com]
>>> Sent: Friday, October 16, 2015 1:34 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [neutron][stable] proactive backporting
>>>
>>> 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:
>>>
>>> https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>>>
>>> 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,
>>>
>>> Ihar
>>
>> Hi,
>>
>> This looks like neat way to do it. In Glance we're doing constantly  
>> proactive backporting and I have been nominating bugs for series' and  
>> approving backports for a while now. We prefer not to have user coming  
>> to us and telling that they hit to bug in "stable" we had known already  
>> for ages, just didn't bother to backport the fix.  It has worked out  
>> really well and people are learning to propose these without me needing  
>> to read every single commit message.
>>
>> Good luck, has worked great for us!
>>
>> - Erno
>> __________________________________________________________________________
>> 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