[openstack-dev] [neutron][stable] proactive backporting
rsblendido at suse.com
Mon Dec 21 09:51:16 UTC 2015
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  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
> : https://etherpad.openstack.org/p/stable-bug-candidates-from-master
> Thanks in advance,
> Miguel Angel Ajo <mangelajo at redhat.com> wrote:
>> I thought that may be, some of the work Ihar is proposing, could be
Yes indeed! We can do that.
>> 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"
>> 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
>>>> official projects (neutron, neutron-*aas, python-neutronclient) that is
>>>> intended to straighten our backporting process and make us more
>>>> 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:
>>>> 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
>>>> 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
>>>> 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
>>>> 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
>>> 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)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev