Open Stack

On Tue, Aug 09, 2016 at 10:21:19PM -0400, Matthew Treinish wrote:

> I fully understood the proposal but I still think you're optimizing for the
> wrong thing. We have a community process for doing backports and maintaining
> released versions of OpenStack code. The fundamental problem here is actually
> that the parties you've identified aren't actively involved in stable branch
> maintenance. The stable maint team and policy was primarily created as a
> solution to the exact problem you outlined above, that it providing a place for
> vendors, distros, etc to collaborate on backports and stable branch maint.
> while following our communities process. Regardless of framing it as being only
> for drivers it doesn't change that you're talking about the same thing. (this is
> why in-tree vs out-of-tree was coming up from others, because if it was
> out-of-tree then you don't have to respect the stable policy)
> 
> What I was getting at before was if instead of ignoring all the previous
> conversations we've had about this exact topic (including 2 sessions in Austin)
> and people actually stepped up and got involved we wouldn't be having this
> discussion today. More than likely we'd have enough people to actually maintain
> a stable branch for longer than we can today. But, instead it feels like our
> community process for code review and actually testing proposed backports is too
> much of a burden for any of these parties you've identified to bother getting
> involved. So we're instead in a situation where we have a proposal to actively
> circumvent our community policy and procedures for maintaining stable branches.
> 
> Creating a free space where vendors can push whatever they want without any
> gating is not only contrary to our stable branch policy but also goes against
> some of the fundamental tenants of OpenStack. It's not something I think we
> should ever be doing.
> 
> > 
> > If this isn't something we can come to an agreement on as a community, then
> > I'd suggest we just create our own repo on github outside of upstream and
> > have it serve the same purpose.
> > 
> 
> If you're dead set on doing this then I think that's your only recourse, because
> what you're attempting to do is something outside our community processes and
> I don't think it has any place in upstream. But, I really think it'd be much
> better if instead of going off into a corner that all of the people who have
> complained about the state of our current stable support windows and stable
> policy actually got involved in this space. That way over time we can make
> the stable branches something where we can have longer support windows. 
> 
> -Matt Treinish

I appologise for weighing in so late.  This is a complex issue with no answer today :(

I think think Matt's email neatly sums up my position.  The stable policy is
the way it is to balance support requirements and community effort.  Any effort
to extend/alter the stable life-cycle needs to start *now* with bodies on the
ground in cinder, infra and the stable team working together to enable this
goal.  A patch to the policy isn't really going to cut it.

Even splitting the drivers out wont work long term, without the effort on
stable support.

I've advocated for the last 12months to lengthen the support cycles, and will
do again as soon as I feel the balance tip towards success.

In short come to the stable team ... we have cookies[1]

Yours Tony.

[1] Collectable at summits, and select mid-cycles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160810/3bf0b59b/attachment.pgp>