Open Stack

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