[all][tc] Relmgt team position on release cadence

Sean Mooney smooney at redhat.com
Mon Nov 29 14:22:31 UTC 2021


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.

stable branches dont nessiarly help with that but not having a very long release cadnce does.

> 
> Regards,
> JP
> 




More information about the openstack-discuss mailing list