Open Stack

Excerpts from Clint Byrum's message of 2015-11-06 10:50:23 -0800:
> Excerpts from Doug Hellmann's message of 2015-11-06 10:28:41 -0800:
> > Excerpts from Clint Byrum's message of 2015-11-06 10:12:21 -0800:
> > > Excerpts from Dan Smith's message of 2015-11-06 09:37:44 -0800:
> > > > > Worth mentioning that OpenStack releases that come out at the same time
> > > > > as Ubuntu LTS releases (12.04 + Essex, 14.04 + Icehouse, 16.04 + Mitaka)
> > > > > are supported for 5 years by Canonical so are already kind of an LTS.
> > > > > Support in this context means patches, updates and commercial support
> > > > > (for a fee).
> > > > > For paying customers 3 years of patches, updates and commercial support
> > > > > for April releases, (Kilo, O, Q etc..) is also available.
> > > > 
> > > > Yeah. IMHO, this is what you pay your vendor for. I don't think upstream
> > > > maintaining an older release for so long is a good use of people or CI
> > > > resources, especially given how hard it can be for us to keep even
> > > > recent stable releases working and maintained.
> > > > 
> > > 
> > > The argument in the original post, I think, is that we should not
> > > stand in the way of the vendors continuing to collaborate on stable
> > > maintenance in the upstream context after the EOL date. We already have
> > > distro vendors doing work in the stable branches, but at EOL we push
> > > them off to their respective distro-specific homes.
> > > 
> > > As much as I'd like everyone to get on the CD train, I think it might
> > > make sense to enable the vendors to not diverge, but instead let them
> > > show up with people and commitment and say "Hey we're going to keep
> > > Juno/Mitaka/etc alive!".
> > > 
> > > So perhaps what would make sense is defining a process by which they can
> > > make that happen.
> > 
> > Do we need a new process? Aren't the existing stable maintenance
> > and infrastructure teams clearly defined?
> > 
> > We have this discussion whenever a release is about to go EOL, and
> > the result is more or less the same each time. The burden of
> > maintaining stable branches for longer than we do is currently
> > greater than the resources being applied upstream to do that
> > maintenance. Until that changes, I don't realistically see us being
> > able to increase the community's commitment. That's not a lack of
> > willingness, just an assessment of our current resources.
> 
> I tend to agree with you. I only bring up a new process because I wonder
> if the distro vendors would even be interested in collaborating on this,
> or if this is just sort of "what they do" and we should accept that
> they're going to do it outside upstream no matter how easy we make it.
> 
> If we do believe that, and are OK with that, then we should not extend
> EOL's, and we should make sure users understand that when they choose
> the source of their OpenStack software.

OK, sure. If we can improve the process, then we should discuss that. We
did accommodate distro requests to continue tagging stable releases for
Liberty, but I'm not sure that compromise was made as the result of
promises of more resources.

Thierry did bring up the idea that the stable maintenance team should
stand alone, rather than being part of the release management team. That
would give the team its own PTL, and give them more autonomy about
deciding stable processes. I support the idea, but no one has come
forward and offered to drive it, yet.

Doug