Open Stack

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.

-- 
Best,
Samuel Cassiba