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
[1]: https://etherpad.openstack.org/p/stable-bug-candidates-from-master
Thanks in advance,
Ihar
Miguel Angel Ajo <mangel...@redhat.com> wrote:
I thought that may be, some of the work Ihar is proposing, could be
automated.
Yes indeed! We can do that.
cheers,
Rossella
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"
guidelines.
Kuvaja, Erno wrote:
-----Original Message-----
From: Ihar Hrachyshka [mailto:ihrac...@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
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
Hi,
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)
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
__________________________________________________________________________
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
