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)
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
