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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
