Open Stack

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