Open Stack

On 11/6/2015 4:43 AM, Thierry Carrez wrote:
> Tony Breeds wrote:
>> [...]
>> 1) Is it even possible to keep Juno alive (is the impact on the project as
>>     a whole acceptable)?
>
> It is *technically* possible, imho. The main cost to keep it is that the
> branches get regularly broken by various other changes, and those breaks
> are non-trivial to fix (we have taken steps to make branches more
> resilient, but those only started to appear in stable/liberty). The
> issues sometimes propagate (through upgrade testing) to master, at which
> point it becomes everyone's problem to fix it. The burden ends up
> falling on the usual gate fixers heroes, a rare resource we need to protect.
>
> So it's easy to say "we should keep the branch since so many people
> still use it", unless we have significantly more people working on (and
> capable of) fixing it when it's broken, the impact on the project is
> just not acceptable.
>
> It's not the first time this has been suggested, and every time our
> answer was "push more resources in fixing existing stable branches and
> we might reconsider it". We got promised lots of support. But I don't
> think we have yet seen real change in that area (I still see the same
> usual suspects fixing stable gates), and things can still barely keep
> afloat with our current end-of-life policy...
>
> Stable branches also come with security support, so keeping more
> branches opened mechanically adds to the work of the Vulnerability
> Management Team, another rare resource.
>
> There are other hidden costs on the infrastructure side (we can't get
> rid of a number of things that we have moved away from until the old
> branch still needing those things is around), but I'll let someone
> closer to the metal answer that one.
>
>> Assuming a positive answer:
>>
>> 2) Who's going to do the work?
>>      - Me, who else?
>> 3) What do we do if people don't actually do the work but we as a community
>>     have made a commitment?
>
> In the past, that generally meant people opposed to the idea of
> extending support periods having to stand up for the community promise
> and fix the mess in the end.
>
> PS: stable gates are currently broken for horizon/juno, trove/kilo, and
> neutron-lbaas/liberty.
>
>
>
> __________________________________________________________________________
> 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 general I'm in favor of trying to keep the stable branches available 
as long as possible because of (1) lots of production deployments not 
upgrading as fast as we (the dev team) assume they are and (2) 
backporting security fixes upstream is much nicer as a community than 
doing it out of tree when you support 5+ years of releases.

Having said that, the downside points above are very valid, i.e. not 
enough resources to help, we want to drop py26, things get wedged easily 
and there aren't people around to monitor or fix it, or understand how 
all of the stable branch + infra + QA stuff fits together.

It also extends the life and number of tests that need to be run against 
things in Tempest, which already runs several dozen jobs per change 
proposed today (since Tempest is branchless).

At this point stable/juno is pretty much a goner, IMO. The last few 
months of activity that I've been involved in have been dealing with 
requirements capping issues, which as we've seen you fix one issue to 
unwedge a project and with the g-r syncs we end up breaking 2 other 
projects, and the cycle never ends.

This is not as problematic in stable/kilo because we've done a better 
job of isolating versions in g-r from the start, but things won't get 
really good until stable/liberty when we've got upper-constraints in action.

So I'm optimistic that we can keep stable/kilo around and working longer 
than what we've normally done in the past, but I don't hold out much 
hope for stable/juno at this point given it's current state.

-- 

Thanks,

Matt Riedemann