Open Stack

On Tue, Nov 30, 2021 at 1:13 PM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>
>  ---- On Mon, 29 Nov 2021 08:22:31 -0600 Sean Mooney <smooney at redhat.com> wrote ----
>  > On Mon, 2021-11-29 at 14:43 +0100, Jean-Philippe Evrard wrote:
>  > > On Mon, Nov 29, 2021, at 14:09, Jeremy Stanley wrote:
>  > > > The primary reason stable branches exist is to make it easier for us
>  > > > to test and publish backports of critical patches to older versions
>  > > > of the software, rather than expecting our downstream consumers to
>  > > > do that work themselves. If you're saying distribution package
>  > > > maintainers are going to do it anyway and ignore our published
>  > > > backports, then dropping the branching model may make sense, but
>  > > > I've seen evidence to suggest that at least some distros do consume
>  > > > our backports directly.
>  > >
>  > > Don't get me wrong, SUSE is consuming those backports, and (at least was) contributing to them.
>  > > And yes, I doubt that RH/SUSE/Canonical are simply consuming those packages without ever adding their patches on a case by case basis. So yes, those distros are already doing part of their work downstream (and/or upstream). And for a valid reason: it's part of their job :)
>  > >
>  > > Doesn't mean we, as a whole community, still need to cut the work for every single consumer.
>  > > If we are stretched thin, we need to define priorities.
>  > >
>  > > I believe our aggressive policy in terms of branching is hurting the rest of the ecosystem, that's why I needed to say things out loud. I meant the less we branch, the less we backport, the less painful upgrades we have to deal with. It depends on our definition of _when to branch_ of course. Your example of a "critical patch" might be a good reason to branch. We are maybe in a place where this can be on a case by case basis, or that we should improve that definition?
>  > i actully would not consier our branching agressive. i actully think its much longer then the rest of the indesty or ecosystem.
>  > many of the project we consume release on a monthly or quterly basis with some provideing api/abi breaking release once a year.
>  > e.g. dpdk only allows abi breaks in the q4 release i belive every year, the kernel select an lts branch to maintain every year basedon the last release of the year but as a ~6 week release schdule.
>  > i stonely belive it would be healthier for use to release more often then we do. that does not mean i think we should break version compatiably for our distibuted project more often.
>  >
>  > if we released every 6 weeks or once a quater but limited the end user impact of that so that they could mix/match release for up to a year or two that would
>  > be better for our consumers, downstream distirbutionbs and devleopers.
>  >
>  > developers would have to backport less, downstream could ship/rebase on any of the intermidary releases without breaking comparitblet to get features and consume could stay on the stable release and
>  > only upgrade once a year or opt for one of the point release in a year for new features.
>  >
>  > honestly i cant see how release less often will have any effect other then slowing the deleiver of featrue and bug fixes to customers.
>  > i dont think it will help distrobutions reduce there maintance since we will just spend more time backproting features due to the increased wait
>  > time that some of our custoemr will not want to wait for. we still recive feature backport request for our OSP 16 product based on train (sometime 10 and 13 based on newton/qeens respcitivly)
>  >
>  > if i tell our large telco customer "ok the we are two far into Yoga to complete that this cycle so the next upstream release we can target this for is Z and that will release in Q4 2022 and it will
>  > take a year for use to productize that relase so you can expect the feature to be completed in 2023" They will respond with "Well we need it in 2022 so what the ETA for a backport".
>  > if we go from a 6month upstream cycle to a 12 month one that converation chagnes form we can deliver in 9 months to 18 upstream + packaging. shure with a 12 cycle there is more likely hood
>  > we could fit it into the current cycle but it also much  much more painful if we miss a release. there are only a small subset of feature that we can backport downstream
>  > without breaking interoperablity so we assume we can fall back on that.
>
> This is an important point and I think I mentioned it in one of my replies but you have put it nicely. Slowing the pace of getting
> features released/available to users will directly hurt many OpenStack consumers. I know a similar case from telco where
> 6-month waiting time is ok for them but not 1 year (we asked if it is ok to deliver this feature upstream in the Z cycle and they
> said no that is too late). I think there might be many such cases. And people might start doing 'downstream more'
> due to upstream late availability of features.

And yet, they won't be able to get  the software into the field for
just as long, and demands/requirements for feature backports
substantially increases vendor production cost by increasing upgrade
risk, elongating qualification testing/cycles, and ultimately
trickling down to the end operator who now has to wait even longer.

It feels like this is a giant "no win situation", or for you star trek
fans, the Kobayashi Maru.

>
> 2nd impact I see here is on contributors which are always my concern in many forms :). We have fewer contributors
> now a days in upstream, making 1-year release can impact their upstream role from their company side either to implement/
> get-releases any feature or contributions help in multiple areas. That is just my thought but anyone managing the upstream
> contributors budget for their company can validate it.
>
> -gmann
>
>  >
>  > stable branches dont nessiarly help with that but not having a very long release cadnce does.
>  >
>  > >
>  > > Regards,
>  > > JP
>  > >
>  >
>  >
>  >
>