Open Stack

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.

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 ?

-- 
Thierry Carrez (ttx)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151110/2972fe4e/attachment.pgp>