It would also help if the process could split out bug fixes from unit tests. I had a bug fix get stuck while the unit tests were bikesheded for a while, and then the delay of not getting quickly backported to the stable branches then kicked in. All the while I had to patch production clouds by hand with a non upstreamed fix. I'm all for having unit tests to ensure the bugs don't creep back in, but regression bugs should be fixed as quickly as possible.
Thanks, Kevin ________________________________________ From: Edgar Magana [[email protected]] Sent: Friday, October 16, 2015 2:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][stable] proactive backporting + 2 and total support for it. Looking forward to reviewing the first set of them. Edgar On 10/16/15, 5:33 AM, "Ihar Hrachyshka" <[email protected]> wrote: >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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
