Open Stack

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 at nemebean.com 
> <mailto:openstack at 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 at nemebean.com <mailto:openstack at nemebean.com>
>      > <mailto:openstack at nemebean.com <mailto:openstack at 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.
>      >
>