This sounds like a pretty decent idea to me. Considering Neutron's patch merge rate this activity should hopefully not take a consistent chunk of your Friday. It might also make sense to ask contributors to resume the habit of tagging bugs with 'backport-potential' even if not in the RC period.
I am glad to offer my help as well in evaluating "backport worthiness", and the process you outlined looks very good to me. If there's any discussion needed for assessing whether a bug fix should be backported or not, we could either use the etherpad or launchpad, with a slight preference for launchpad. Salvatore On 16 October 2015 at 16:19, Kyle Mestery <[email protected]> wrote: > On Fri, Oct 16, 2015 at 7: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, >> >> Wow, this is a great idea Ihar! Thanks for taking this on! Count me in on > helping with this effort as well. > > Thanks, > Kyle > > >> 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 > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
