On 9/26/19 7:17 PM, Donny Davis wrote:
So when you say largely ignored, do you mean by downstream vendors who package Openstack or by public clouds who use it daily? I can see a longer release cycle being better for vendors so they don't have to do FFU to begin with and public clouds wanting faster releases so they can get features to customers sooner.
I see FFU as our longer release cycle though. Since it's a supported path, I'm not sure it makes sense to try to work around that. As far as public cloud, I don't have as much insight as I haven't worked directly with as many of them. I can say that as a user who at one point needed some recent features, plenty of public clouds were not running the latest release either. There were a few that did track releases pretty closely, but many were 2 or 3 behind. Admittedly, that was a couple of years ago so I don't know the current state of public clouds. I guess the OpenStack user survey probably holds the answer to that.
On Thu, Sep 26, 2019 at 4:34 PM Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com>> wrote:
On 9/26/19 11:29 AM, Donny Davis wrote: > So would a longer release cycle help or hurt that? Would having two > trains make it better or worse?
My prediction is that the shorter release cycle train would be largely ignored, and the feature freeze madness for the longer cycle would be even worse. That's nothing more than an educated guess on my part though.
It also may still be worth it to move to the longer cycle. On some level, the feature freeze crunch is going to happen anyway. At least that way it happens less often.
> > Just want to make things clear that I am only curious and wanted to > share what I see. > > ~/D > > On Thu, Sep 26, 2019 at 12:17 PM Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com> > <mailto:openstack@nemebean.com <mailto:openstack@nemebean.com>>> wrote: > > > > On 9/26/19 9:42 AM, Matt Riedemann wrote: > > In last week's nova meeting we also talked about some of this > [1]. If > > you change the release cycle to do major and minor versions, that's > > going to be pretty complicated for testing upgrades, because grenade > > goes from major to major based on branches. We could probably > make it > > work (and maybe it's already possible, I don't know to go from tag > > (minor release) to master, but the point is you're going to blow > up the > > upgrade test matrix and it's not clear anyone is even going to be > > consuming those minor intermediate releases. I think this is > partly why > > the release team stopped doing a cycle-with-milestone [2] release > > because no one was consuming the milestone releases. > > We've even found that since we started supporting FFU between certain > releases that many customers won't touch the intervening releases, even > with six months between them. They're basically on a year-and-a-half > cycle. This actually makes things worse for the FFU releases because > having a feature miss one means waiting that much longer for it to show > up (or we have to carry downstream backports, which sucks). > > I know we'd like to have everyone CD'ing master, but for the > foreseeable > future I think it's more likely that we're going to have a non-trivial > number of deployers who stick to the longest release cycle that can be > supported, and that's going to create added pressure during feature > freeze for whatever that release is. >