Open Stack

On Fri, Nov 06, 2015 at 10:12:21AM -0800, Clint Byrum wrote:

> The argument in the original post, I think, is that we should not
> stand in the way of the vendors continuing to collaborate on stable
> maintenance in the upstream context after the EOL date. We already have
> distro vendors doing work in the stable branches, but at EOL we push
> them off to their respective distro-specific homes.

That is indeed a better summary than I started with.

I have a half formed idea that creates a state between the current EOL (where
we delete the branches) to what we have today (where we have full CI/VMT/Release
management.

There is a massive ammount of trust involved in that simple statement and I don't
underestimate that.

This would provide a place where interested vendors can work together.
We could disable grenade in juno which isn't awesome but removes the gotta land
patch in juno, kilo and liberty to unblock the master gate.
We could reduce the VMT impact by nominating a point of contact for juno and
granting that person access to the embargoed bugs.  Similarly we could
trust/delegate a certain about of the release management to that team (I say
team but so far we've only got one volunteer)

We can't ignore the fact that fixing things in Juno *may* still require fixes
in Kilo (and later releases) esp. given the mess that is requirements in
stable/juno
 
> As much as I'd like everyone to get on the CD train, I think it might
> make sense to enable the vendors to not diverge, but instead let them
> show up with people and commitment and say "Hey we're going to keep
> Juno/Mitaka/etc alive!".
> 
> So perhaps what would make sense is defining a process by which they can
> make that happen.
> 
> Note that it's not just backporters though. It's infra resources too.

Sure.  CI and Python 2.6 I have a little understanding of.  I guess I can
extrapolate the additional burden on {system,project}-config.  I willingly
admit I don't have a detailed feel for what I'm asking here.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151109/bf963a4b/attachment.pgp>