Clint Byrum wrote:
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.
Except for the fact that you are now forcing deployers that may or may
not be ok with paying for paid support to now pay for it... What is the
adoption rate/expected adoption rate of someone transitioning there
current cloud (which they did not pay support for) to a paid support model?
Does that require them to redeploy/convert there whole cloud using
vendors provided packages/deployment model... If so, jeez, that sounds
iffy...
And if a large majority of deployers aren't able to do that conversion
(or aren't willing to pay for support) and those same deployers are
willing to provide developers/others to ensure the old branches continue
to work and they know the issues of CI and they are willing to stay
on-top of that (a old-branch-dictator/leader may be needed to ensure
this?) then meh, I think we as a community should just let those
deployers have at it (ensuring they keep on working on the old branches
via what 'old-branch-dictator/leader/group' says is broken/needs fixing...)
My 2 cents,
Josh
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
