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