Open Stack

On Mon, Nov 09, 2015 at 05:28:45PM -0500, Doug Hellmann wrote:
> Excerpts from Matt Riedemann's message of 2015-11-09 16:05:29 -0600:
> > 
> > On 11/9/2015 10:41 AM, Thierry Carrez 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
> > 
> > Isn't this kind of already what the stable maint team does? Well, that 
> > and some QA people like mtreinish and sdague.
> > 
> > >
> > > 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
> > >
> > 
> > With the decentralizing of the stable branch stuff in Liberty [1] it 
> > seems like there would be less use for a PTL for stable branch 
> > maintenance - the cats are now herding themselves, right? Or at least 
> > that's the plan as far as I understood it. And the existing stable 
> > branch wizards are more or less around for help and answering questions.
> 
> The same might be said about releasing from master and the release
> management team. There's still some benefit to having people dedicated
> to making sure projects all agree to sane policies and to keep up with
> deliverables that need to be released.

Except the distinction is that relmgt is actually producing something. Relmgt
has the releases repo which does centralize library releases, reno to do the
release notes, etc. What does the global stable core do? Right now it's there
almost entirely to just add people to the project specific stable core teams.

-Matt Treinish

> > 
> > [1] 
> > http://lists.openstack.org/pipermail/openstack-dev/2015-November/078281.html
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151109/295c8ba3/attachment.pgp>