On 03/23/2016 05:52 PM, Ihar Hrachyshka wrote: > Hey folks, > > some update on proactive backporting for neutron, and a call for action > from subteam leaders. > > As you probably know, lately we started to backport a lot of bug fixes > in latest stable branch (liberty atm) + became more systematic in > getting High+ bug fixes into older stable branch (kilo atm). > > I work on some tooling lately to get the process a bit more straight: > > https://review.openstack.org/#/q/project:openstack-infra/release-tools+owner:%22Ihar+Hrachyshka+%253Cihrachys%2540redhat.com%253E%22 > > > I am at the point where I can issue a single command and get the list of > bugs fixed in master since previous check, with Wishlist bugs filtered > out [since those are not applicable for backporting]. The pipeline looks > like: > > ./bugs-fixed-since.py neutron <prevhash> | > ./lp-filter-bugs-by-importance.py --importance=Wishlist neutron | > ./get-lp-links.py > > For Kilo, we probably also need to add another filter for Low impact bugs: > > ./lp-filter-bugs-by-importance.py --importance=Low neutron > > There are more ideas on how to automate the process (specifically, kilo > backports should probably be postponed till Liberty patches land and be > handled in a separate workflow pipeline since old-stable criteria are > different; also, the pipeline should fully automate ‘easy' backport > proposals, doing cherry-pick and PS upload for the caller).
Wow, great work, thanks a lot! > > However we generate the list of backport candidates, in the end the bug > list is briefly triaged and categorized and put into the etherpad: > > https://etherpad.openstack.org/p/stable-bug-candidates-from-master > > I backport some fixes that are easy to cherry-pick myself. (easy == with > a press of a button in gerrit UI) > > Still, we have a lot of backport candidates that require special > attention in the etherpad. > > I ask folks that cover specific topics in our community (f.e. Assaf for > testing; Carl and Oleg for DVR/L3; John for IPAM; etc.) to look at the > current list, book some patches for your subteams to backport, and make > sure the fixes land in stable. I've gone through the L2 and ML2 section. I backported missing patches and added comments where I think no backport is needed. cheers, Rossella > > Note that the process generates a lot of traffic on stable branches, and > that’s why we want more frequent releases. We can’t achieve that on kilo > since kilo stable is still in the integrated release mode, but starting > from Liberty we should release more often. It’s on my todo to document > release process in neutron devref. > > For your reference, it’s just a matter of calling inside > openstack/releases repo: > > ./tools/new_release.sh liberty neutron bugfix > > FYI I just posted a new Liberty release patch at: > https://review.openstack.org/296608 > > Thanks for attention, > > Ihar Hrachyshka <ihrac...@redhat.com> wrote: > >> Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >>> Rossella Sblendido <rsblend...@suse.com> wrote: >>> >>>> 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 >>> >>> I don’t think it will work. First, not everyone should be required to >>> care about stable branches. It’s my belief that we should avoid >>> formal requirements that mechanically offload burden from stable team >>> to those who can’t possible care less about master. >> >> Of course I meant ‘about stable branches’. >> >> Ihar >> >> __________________________________________________________________________ >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
