settingsLogin | Registersettings

[openstack-dev] Upstream LTS Releases

0 votes

Hello Ops folks,

This morning at the Sydney Summit we had a very well attended and very
productive session about how to go about keeping a selection of past
releases available and maintained for a longer period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our amazing UC (User Committee) will
be begin working out the details.

Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 15, 2017 in openstack-operators by Erik_McCormick (3,880 points)   2 3

22 Responses

0 votes

Excerpts from Doug Hellmann's message of 2017-11-11 12:19:56 -0500:

Excerpts from John Dickinson's message of 2017-11-10 14:51:08 -0800:

On 7 Nov 2017, at 15:28, Erik McCormick wrote:

Hello Ops folks,

This morning at the Sydney Summit we had a very well attended and very
productive session about how to go about keeping a selection of past
releases available and maintained for a longer period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

The concept, in general, is to create a new set of cores from these
groups, and use 3rd party CI to validate patches. There are lots of
details to be worked out yet, but our amazing UC (User Committee) will
be begin working out the details.

Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

I'm not a fan of the current proposal. I feel like the discussion jumped into a policy/procedure solution without getting much more feedback from operators. The room heard "ops want LTS" and we now have a new governance model to work out.

What I heard from ops in the room is that they want (to start) one release a year who's branch isn't deleted after a year. What if that's exactly what we did? I propose that OpenStack only do one release a year instead of two. We still keep N-2 stable releases around. We still do backports to all open stable branches. We still do all the things we're doing now, we just do it once a year instead of twice.

We have so far only been able to find people to maintain stable
branches for 12-18 months. Keeping N-2 branches for annual releases
open would mean extending that support period to 2+ years. So, if
we're going to do that, we need to address the fact that we haven't
been able to retain anyone's attention that long up to this point.
Do you think keeping the branches open longer will be sufficient
to attract contributors to actually work on them?

I don't think that, no. However, I do think if you also relieved the
current stable release pressure by cutting stable releases less often,
you'd be tasking the same backporters and maintainers with the same
amount of work. The difference would be that the work done early in a
cycle would mean more, as it would last longer, and thus might get
a bump in priority and overall community efficiency.

It's not all free though. There's a balancing act to play here. If you
force users to wait longer for things that aren't being backported,
they're likely to diverge more downstream


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Nov 13, 2017 by Clint_Byrum (40,940 points)   4 5 6
0 votes

John Dickinson wrote:
What I heard from ops in the room is that they want (to start) one
release a year who's branch isn't deleted after a year. What if that's
exactly what we did? I propose that OpenStack only do one release a year
instead of two. We still keep N-2 stable releases around. We still do
backports to all open stable branches. We still do all the things we're
doing now, we just do it once a year instead of twice.

I started a thread around this specific suggestion on the -sigs list at:

http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.html

Please continue the discussion there, to avoid the cross-posting.

If you haven't already, please subscribe at:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 15, 2017 by Thierry_Carrez (57,480 points)   3 7 12
...