Open Stack

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

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

Yes indeed! We can do that.

cheers,

Rossella

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