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