Open Stack

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
> <emccormick at cirrusseven.com> 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 Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 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
> ignored.
>
> 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
OK.

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
not required.

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.

Doug