Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800:
On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick
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.
Thanks to everyone who participated!
OpenStack Development Mailing List (not for usage questions)
In advance, pardon the defensive tone. I was not in a position to
attend, or even be in Sydney. However, as this comes across the ML, I
can't help but get the impression this effort would be forcing more
work on already stretched teams, ie. deployment-focused development
teams already under a crunch as contributor count continues to decline
in favor of other projects inside and out of OpenStack.
As a friendly reminder, Chef is still actively developed, though we've
not had a great return from recruiting more people. We have about 3.5
active developers, including active cores, and non-cores who felt it
worthwhile to contribute back upstream. There is no major corporate
backer here, but merely a handful of potentially stubborn volunteers.
Nobody is behind the curtain, but Chef OpenStack still have a few
active users (once again, I point to the annual User Survey results)
and contributors. However, we do not use the MLs as a primary
communication means, so I can see how we might be forgotten or
In practice, no one likes talking about Chef OpenStack that I've
experienced, neither in the Chef or OpenStack communities. However, as
a maintainer, I keep making it a point to bring it up when it seems
the project gets papered over, or the core team gets signed up for
more work decided in a room half a world away. Admittedly, the whole
deployment method is a hard sell if you're not using Chef in some way.
It has always been my takeaway that the project was merely tolerated
under the OpenStack designation, neither embraced nor even liked, even
being the "official" OpenStack deployment method for a major
deployment toolset. The Foundation's support has been outstanding when
we've needed it, but that's about as far as the delightful goes. The
Chef community is a bit more tolerant of someone using the Chef
moniker for OpenStack, but migrating from Gerrit to GitHub is a major
undertaking that the development team may or may not be able to
reasonably support without more volunteers. Now that the proposition
exists about making a Stable Release liaison derived from existing
cores, I can't help but get the impression that, for active-but-quiet
projects, it'll be yet another PTL responsibility to keep up with, in
addition to the rigors that already come with the role. I'm hoping
I'll be proven wrong here, but I can and do get in trouble for hoping.
There are still a lot of details to work out, so the announcement
of an "agreement" is a bit premature. Rest assured, however, that
the proposed change is not about "requiring," or even asking, anyone
to do any new work that they don't want to do.
In the past, we asked folks who wanted to have old branches maintained
for a long time to join our stable management team with the premise
that if the stable team grew it could support more branches for
longer. We've been repeating that answer for about 5 years now,
without much success, in part because the expertise needed to
actually deal with complex failures of stable branch jobs is not
widely available and gaining the experience is a huge time commitment
that most users can't afford. It should be clear to everyone that
the previous approach isn't working.
The new proposal is meant to empower people who want to do work
to have a place to do it. At the same time, we need to lower the
expectations of what is likely to be produced by recognizing that
the older the branches get the more brittle they will become. We
also want to ensure that any burden created by taking on more work
is absorbed by the people doing the work, and does not unduly impact
the folks not interested in doing it.
With those caveats in mind, the idea is to continue the current
stable policy, more or less as it is, with development teams taking
responsibility for backports within a couple of stable branches.
Then at the point in time that we now call the "end of life" for a
branch, instead of deleting it we would leave it open and establish
a new team of people who want to continue to maintain that
branch. We anticipate the members of those new teams coming mostly
from users and distributors, based on who are using the release by
deploying it themselves or supporting it for their customers. Not
all branches are going to attract teams to maintain them, and that's
After the switch from stable to whatever we are calling this new
phase, we will stop tagging releases so that consumers of the branch
have a clear indication that the level of support has changed.
Backports and other fixes can be shared, but to consume them a user
will have to build their own packages.
Regarding testing, my recollection is that we would leave jobs
running as they are, and as they break down the team that maintains
the branch could decide how to deal with them. Fixing the jobs
upstream where possible is preferred, but depending on who is
maintaining the branch, the level of support they are actually
providing, and the nature of the breakage we said that removing
individual tests or whole jobs is another option. The use of
third-party testing came up as another area of flexibility, but is
Erik and some other folks from the session are going to need to
write up some policy and process change proposals so we can hash
out all of the details and make sure we're all agreeing to what we
think we're agreeing to. Nothing will change until that more complete
discussion happens, so as Thierry said watch for that thread.