Open Stack

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.

> 
>> That said, I'm staunchly opposed to feature backports.  While I think it
>> makes perfect sense to allow backports like Giulio's,
> 
> Yup with my limited knowledge I think that review makes perfect sense to
> backport.  It just doesn't match the *current* stable policy.
> 
> <snip parts of the wall-o-text ;P>
>   
>> It feels a little weird to me to be arguing this side of it because I'm
>> pretty sure I've argued against splitting repos in the past.  But I think I
>> would not say we kick all the vendor-integration bits out if we do this,
>> just that we provide the option for vendors to have their own repos with
>> their own stable backport policies without having to change the policy for
>> all of TripleO at the same time.
> 
> If splitting the repos has good technical benefits then cool, if it's
> mostly about matching policy then I think altering the policy (or
> defining a new one is a better solution)
>   
>> And I'm also open to other approaches like tweaking the cycle-trailing
>> definition to allow more time for this sort of thing.  Maybe we could
>> eliminate some of the need for feature backports if we did that.
> 
> I'm not sure I follow but sure altering the timeline within reason is a
> simple thing to do.

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.

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. :-)