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