On 2016-04-19 09:22:57 -0400 (-0400), Doug Hellmann wrote: > Excerpts from Ian Wienand's message of 2016-04-19 12:11:35 +1000: [...] > > I don't expect the stable release team to be involved with all this; > > but if we miss windows then we're left either going to efforts getting > > one of a handful of people with permissions to do manual rebuilds or > > waiting yet another day to get something fixed. Add some timezones > > into this, and simple fixes are taking many days to get into builds. > > Thus adding points where we can extend this by another 24 hours > > really, well, sucks. > > How often does that situation actually come up?
Semi-often. The project is officially under TripleO but it's sort of a shared jurisdiction between some TripleO and Infra contributors. I think the release team for diskimage-builder used to shoot for tagging weekly (sans emergencies), though that's slacked off a bit and is more like every 2 weeks lately. DIB is an unfortunate combination of a mostly stable framework and a large pre-written set of scripts and declarative data which is constantly evolving for widespread use outside the OpenStack ecosystem (so most of the change volume is to the latter). As Ian points out, the Infra team has already been tempted to stop relying on DIB releases at all (or worse, maintain a fork) to reduce overall latency for getting emergency fixes reflected in our worker images. I suspect that most of the concern over using OpenStack release process for DIB (and similarly Infra projects) is that the added complexities introduce delays, especially if there's not a release team member available to do on-the-spot approvals on weekends and such. I don't know whether extending that to add tagging ACLs for the library-release group would help? That would bring the total up to 6 people, two more of whom are in non-American timezones, so might be worth a try. It's also worth keeping in mind that we've sort of already identified two classes of official OpenStack projects. One is "OpenStack the Product" only able to be distributed under the Apache license and its contributors bound by a contributor license agreement. The other is the output of a loose collective of groups writing ancillary tooling consumed by the OpenStack community and also often used for a lot of other things completely unrelated to OpenStack. I can see where strict coordinated release process and consistency for the former makes sense, but a lot of projects in the latter category likely see it as unnecessary overkill for their releases. -- Jeremy Stanley __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
