Open Stack

Thierry Carrez <thierry at openstack.org> wrote:

> Hi everyone,
>
> A few cycles ago we set up the Release Cycle Management team which was a
> bit of a frankenteam of the things I happened to be leading: release
> management, stable branch maintenance and vulnerability management.
> While you could argue that there was some overlap between those
> functions (as in, "all these things need to be released") logic was not
> the primary reason they were put together.
>
> When the Security Team was created, the VMT was spinned out of the
> Release Cycle Management team and joined there. Now I think we should
> spin out stable branch maintenance as well:
>
> * A good chunk of the stable team work used to be stable point release
> management, but as of stable/liberty this is now done by the release
> management team and triggered by the project-specific stable maintenance
> teams, so there is no more overlap in tooling used there
>
> * Following the kilo reform, the stable team is now focused on defining
> and enforcing a common stable branch policy[1], rather than approving
> every patch. Being more visible and having more dedicated members can
> only help in that very specific mission
>
> * The release team is now headed by Doug Hellmann, who is focused on
> release management and does not have the history I had with stable
> branch policy. So it might be the right moment to refocus release
> management solely on release management and get the stable team its own
> leadership
>
> * Empowering that team to make its own decisions, giving it more
> visibility and recognition will hopefully lead to more resources being
> dedicated to it
>
> * If the team expands, it could finally own stable branch health and
> gate fixing. If that ends up all falling under the same roof, that team
> could make decisions on support timeframes as well, since it will be the
> primary resource to make that work
>
> So.. good idea ? bad idea ? What do current stable-maint-core[2] members
> think of that ? Who thinks they could step up to lead that team ?
>
> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> [2] https://review.openstack.org/#/admin/groups/530,members
>
> -- 
> Thierry Carrez (ttx)

Lots of great thoughts in the thread, trying to catch up with it.

I lean towards supporting the split; if anything, to make responsibilities  
more clear. Currently, [especially since we disintegrated the monolithic  
stable-maint team into per-project teams] I struggle to reach the whole  
stable team and get some final decisions on unclear matters set. F.e. I  
sent several [stable] emails to this ML recently that would require some  
more input from outside neutron-stable-maint that I am part of, and I don’t  
see enough responses, neither a way to understand where the discussion  
leaned and what my next steps are.

I believe if we have a dedicated team for the effort, we would at least be  
able to get more attention to such discussions, and hopefully would be able  
to make final calls on policies common to the whole project.

I am not sure we actually *require* PTL for that to happen, though I also  
don’t see it a bad thing if we do have the role. [And if you wonder, I  
won’t be able to run for PTL for the project but I am happy to help the  
cause.]

I think the main responsibility of the team would be enabling other,  
per-project teams to do their job. Meaning, handling common policy  
questions; providing tools where needed; spearheading and monitoring  
initiatives that would make stable branches less broken; providing guidance  
to project teams on how to manage stable branches properly, thru docs and  
irc/email support; making calls on support phases and their length; etc.

Obviously it is not a full blown software project; separating concerns  
seems justified here nevertheless.

Ihar