On 11/13/2015 8:10 AM, Thierry Carrez wrote:
So.. quick summary of this thread so far.
(-)
* Not enough work to warrant a designated "team", now that the work is
decentralized and the cats are mostly herding themselves
* The change is unlikely to bring a meaningful improvement to the
situation, or sudden new resources
(+)
* An empowered team could tackle new coordination tasks, like engaging
more directly in converging stable branch rules across teams, or
producing tools
* Release management doesn't overlap anymore with stable branch, so
having them under that PTL is limiting and inefficient
* Reinforcing the branding (by giving it its own team) may encourage
more organizations to affect new resources to it
In summary, I think this is worth a try. If the team fails, at least it
will be on its own rather than as the 5th squeaky wheel of release
management (where lack of leadership and focus could be rightly blamed
for failure).
For this to succeed, we need someone to own the effort and push it
forward, and a number of people caring enough about it to attend regular
meetings about it and to lurk on #openstack-stable. I'm fine helping the
team in the spin-off effort but I don't want to lead it (I proved I was
unable to make it my top priority in the past, so I think the team
deserves a more focused lead).
Erno has volunteered to lead. Ihar, Alan (Pevec) and myself don't have
enough time to lead but are happy to help. Anyone else interested to
join that initial group ? Flavio ? Matt ?
Once we have a list of key members we should set up a meeting to discuss
the details.
I've been doing some thinking in the last week and I'm going to throw my
hat in the ring for leading this. I've definitely played devil's
advocate in this thread, but I think it also points out several issues
that are going to require some focused work and communication and I
think I'm suited to lead that.
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.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
