Open Stack

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