Open Stack

On Wed, Sep 27, 2017 at 10:17:16PM -0500, Ben Nemec wrote:
> 
> 
> On 09/27/2017 08:13 PM, Tony Breeds wrote:
> > On Wed, Sep 27, 2017 at 03:35:43PM -0500, Ben Nemec wrote:
> > > It's a little weird because essentially we want to provide a higher level of
> > > support for stable branches than most of OpenStack.  My understanding is
> > > that a lot of the current stable branch policy came out of the fact that
> > > there was a great deal of apathy toward stable branches in upstream
> > > OpenStack and it just wasn't possible to say we'd do more than critical bug
> > > and security fixes for older releases.  Maybe we need a stable-policy-plus
> > > tag or something for projects that can and want to do more.  And feel free
> > > to correct me if I'm misinterpreted the historical discussions on this. :-)
> > 
> > That's mostly accurate but the policy also is an indication that
> > consumers should be moving along to newer releases.  For a whole host of
> > reasons that isn't working and it's a thing that we need to address as a
> > community.
> 
> Ah, I wasn't familiar with that aspect of it.  I guess that's a valid reason
> not to continue full support of stable branches even if you theoretically
> could.
> 
> > 
> > The current policy broadly defines 3 phases[1]:
> > 
> > Phase   Time frame        Summary                Changes Supported
> > I       First 6 months    Latest release         All bugfixes (that meet the
> >                                                   criteria described below) are
> >                                                   appropriate
> > II      6-12 months       Maintained release     Only critical bugfixes and
> >          after release                            security patches are acceptable
> > III     more than 12      Legacy release         Only security patches are acceptable
> >          months after
> >          release
> > 
> > I can see a policy looked more like:
> > 
> > Phase    Time frame        Summary             Changes Supported
> > I        0-12 months       Maintained release  All bugfixes (that meet the
> >          after release                          criteria described below) are
> >                                                 appropriate
> > II      more than 12     Legacy release        Only security patches are acceptable
> >          months after
> >          release
> > 
> > The 12 month mark is really only there to line up with our current EOL
> > plans, if they changed then we'd need to match them.
> 
> Wouldn't that still exclude the Ceph patch we're using as an example? Newton
> is over 12 months old at this point.
<mode=cheeky>
Newton was released on 2016-10-06 so it isn't *quite* 12months old yet
;P
</mode>

I do take your point.  Right now I feel like there needs to be a point
where projects are switched into a 'legacy' mode I'm open exactly how
that looks and when it happens.


> Yeah, that was not a fully formed thought in my head when I wrote it. :-)  I
> guess I was thinking of somehow allowing more time for features to be done
> after the rest of OpenStack cuts its release, but I don't actually know if
> that would help.

Ah okay that clarifies what you meant :)

That's more of a release management thing that Stable, I suspect that
it'd just move the crunch time a little but who knows.  Sometimes you
just have to try things to see if they work.
 
> One (maybe crazy) thought I had after writing all this was the possibility
> of allowing feature backports for a limited time after release in the
> deployment projects.  Say feature backports are only allowed up to M-1 of
> the next release.  I'm not at all sure I like the idea but it has some
> interesting implications, both good and bad.  Like no more FFE's - if you
> miss release you just have to do the extra work of backporting if you still
> want it in.  So there's motivation to get stuff done on time, but less panic
> around release time.  Of course, somebody's got to review all those
> backports so like I said I'm not convinced it's a good idea, but it's an
> idea. :-)

Certainly worth discussing, that more or less seems like you're
expanding the $series development time from 6months to 7ish.  Perhaps
it'd help that's something that tripleo could try with only small
impacts on other teams.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170928/9ca1b7af/attachment.sig>