On 11/23/2015 11:11 AM, Thierry Carrez wrote:
Hi everyone,
We discussed setting up a standalone stable maintenance team and as part
of this effort we'll be organizing PTL elections over the coming weeks.
We held a preliminary meeting today to converge on team scope and
election mechanisms. The stable team mission is to:
* Define and enforce the common stable branch policy
* Educate and accompany projects as they use stable branches
* Keep CI working on stable branches
* Mentoring/growing the stable maintenance team
* Create and improve stable tooling/automation
Anyone who successfully contributed a stable branch backport over the
last year (on any active stable branch) is considered a stable
contributor and can vote in the Stable PTL election.
If you're interested, please reply to this thread with your
self-nomination (and your platform) in the coming week. Deadline for
self-nomination is 23:59 UTC on Monday, Nov 30. Elections will then be
held if needed the week after.
Thanks!
This is basically a copy of my previous self-nomination reply [1] but
will post it here again for completeness.
Background:
* I've been stable-maint-core since April. I primarily focus on nova
stable branches but also get into other projects when necessary for
critical bugs and blocking gate issues.
* Much of my focus is on the CI issues, i.e. Tony's tangled web of
onions. I already deal enough in QA on trunk that it's a natural
extension to stable branches.
* python-novaclient release liaison.
* I already do quite a bit of stable branch maintenance internally
(which is how I got involved with it upstream too). So I have incentive
to keep it working.
This is basically what I see for PTL of a stable maint team:
1. Helping projects deal with stable branch policy and process. We are
decentralizing now but I suspect there will still be a lot of learning
and cat herding needed in individual projects. This includes being
around to help (I'm always in #openstack-stable) and helping to
coordinate point releases as needed.
2. Keeping the CI system working on stable. This is already something
I've been doing on stable for a long time so that just continues. It
also means keeping a finger on how the periodic nightly jobs are doing
and getting projects involved/aware when their stable branches are
failing (bringing that up in the mailing list, project meetings or a
cross project meeting as needed). An extension of this is seeing what we
can do to try and keep stable branches around longer, which is clearly
something the operator community has been wanting.
3. Mentoring. A big part of this thread is talking about a lack of
resources to work on stable branch issues (usually CI). So part of
mentoring here is identifying and helping people that are wanting to
work in this space. A perfect example is tonyb and the work he's done
the past several months on tracking gate failures and blocking issues.
It also includes keeping track of who's doing a good job with reviews
and seeing if they are ready for core.
4. Identifying official tags for a project, which doesn't just mean they
have a stable branch but that they abide by the stable branch policy
(what's appropriate to backport) and that they are maintaining their
stable branches; this means actually reviewing proposed changes, being
proactive about backporting high severity fixes, and keeping their CI
jobs clean.
5. Looking for ways to improve processes and tooling. One thing that has
come up in this thread was a need for tooling to identify backportable
changes (e.g. a high severity bug is marked as backport potential in
launchpad but no one has done the backport yet). I'm also not entirely
sure we have something today that is tracking stable branch review stats
so that we can identify people that are doing (or cores not doing) reviews.
So this is a bit long-winded but it's what I see as being important for
a separate team and PTL to do in this space. If we're going to do this,
I want to make sure these things are covered and I think I'm in a
position to do that.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079694.html
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
