Open Stack

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.

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.

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

Yours Tony.

[1] https://docs.openstack.org/project-team-guide/stable-branches.html
-------------- 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/1760cb9e/attachment.sig>