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