[openstack-dev] [stable] Making stable maintenance its own OpenStack project team

Thierry Carrez thierry at openstack.org
Wed Nov 18 09:51:50 UTC 2015


Matt Riedemann wrote:
> [...]
> 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.

This is a very good summary. I think it's critical to have good
representation of the "gate fixing" part of the role: without it, the
stable team is basically useless and totally dependent on another group,
with all the tension we had in the past. Growing the next generation of
gate fixers is essential.

I'm mostly away this week at a conference, but now that we have a list
of names, we should set up a meeting early next week to further discuss
team goals and initial leadership.

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list