Open Stack

On Tue, Nov 10, 2015 at 10:13:09AM +0100, Thierry Carrez wrote:
> Matthew Treinish wrote:
> > [...]
> > The discussion here is about the cross project effort around stable branches,
> > which by design is a more limited scope now. Right now the cross project effort
> > around stable branch policy is really 2 things (both of which ttx already
> > mentioned):
> > 
> > 1. Keeping the gates working on the stable branches
> > 2. Defining and enforcing stable branch policy.
> 
> Right. My argument is that we need to expand the work on point (2), and
> then expand the work on point (1), and that empowering them by giving
> them their own team can only help.

Well you know my position on this well, but without people working on #1 policy
changes don't actually do a whole lot. You can look at our "experiment" in a
longer support window last year for proof of that. I don't think coming about
it from the other direction will actually change who looks at gate issues and
how we fail to scale there.

> 
> For point (2), currently the stable branch policy is not really enforced
> as much as it should. I think it's important to have a standard
> definition across OpenStack of what a "stable branch" means in terms of
> acceptable backports, support periods, frequency of point releases, etc.
> With the big tent we see a lot of variance in the stable branch policy,
> and what used to be mostly self-policed is likely to now require a lot
> more attention from policy overlords.
> 
> I'm not seeing that happening with the current team structure, which is
> why I proposed the change. Once empowered with their own team, it will
> be easier to justify dedicating resources to it, and I hope that will go
> all the way up to owning gate fixing when stable branch breaks (point
> (1) which is currently mostly done off-team).
> 
> > The only lever on #2 is that the global stable-maint-core is the only group
> > which has add permissions to the per project stable core groups. (also the
> > stable branch policy wiki, but that rarely changes)
> 
> Actually we'll likely create a "follows-stable-policy" tag that would be
> granted by this team. I expect that to be a good lever as well.
> 
> > [...] 
> > This is my whole argument that creating a new team doesn't do anything. Living
> > under rel-mgt, some other project, or creating a new one isn't going to change
> > the fact that cross-project stable maint is the same 2 tasks which basically
> > nobody cares about, which TBH your email is just an indication of. Even if we
> > wanted to grow to something beyond these 2 tasks they would still be the core of
> > whatever it becomes and a lack of people caring about them will just block any
> > potential scope growth.
> 
> I have evidence that making that group its own project team will result
> in additional resources, and increase of focus from existing resources.
> The alternative is to kill stable branches altogether. But as the other
> thread shows, there is still interest in them, so providing the right
> vessel for resources to be dedicated to it is still worth a try.
> 
> I'm arguing that one of the reasons "nobody cares" is because it's
> always been the 5th wheel of release management, and making it a
> first-class citizen could unlock the situation. I don't see harm in
> trying. Do you ?
> 

No, there is no harm in trying. Maybe I'm just more jaded and bitter, but I just
don't see how making it a separate thing is going to change anything. I don't
expect all the stable unicorns and fairies to come out of the forest and solve
all our problems once they finally have a separate project team. The work has
always been there a dedicated project team doesn't magically create interest
from my POV. If people were truly interested in helping they'd be contributing
already.

-Matt Treinish
-------------- 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/20151110/1a295229/attachment.pgp>