Open Stack

On Wed, Nov 8, 2017 at 11:17 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> 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.

As a three-time PTL for a dead-no-alive-no-dead-maybe-undead-no-alive
open source project, I feel the pain first-hand. I would love to
support Mitaka and cherry-pick changes from Ocata, Pike or Queens, but
today I cannot. I've resorted to begging for anything that helps keep
the project moving forward that I cannot do myself, due to timing or
otherwise.

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

Leaving the branch open for future development is OK with me. I've had
instances in which the codebase was still fresh enough to deliver bug
fixes, but it was against a release marked "End of Lifecycle", and
thus the bug stamped with a happy little WONTFIX. The battered and
beaten support agent I keep locked in my attic is deeply saddened by
these cases when I mention them.

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

At some point, someone will have to say enough's enough, though, but
who makes that call? In Chefland, chef-client grows a new major
release every eight or so months, with a supported lifecycle of N-1,
so it wouldn't be nearly as straightforward as just leaving the branch
open just because someone is willing to own the changes and make sure
the gates still fired. The rest of the ecosystem can decay to a state
of unuse for a given release, as well, due to flipped solar flares and
good old bitrot.

>
> 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
>
> __________________________________________________________________________
> 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

This is a topic of definite interest to me, so I'll keep an eye out to
see what unfolds. Threads don't get tagged with [chef] anymore, and
I'm not in Sydney, so I have to wade through the firehose to even
catch these types of changes before they become reality.

-- 
Best,
Samuel Cassiba