❦ 31 mars 2021 12:46 +02, Willy Tarreau:
> On the kernel Greg solved all this by issuing all versions very
> frequently: as long as you produce updates faster than users are
> willing to deploy them, they can choose what to do. It just requires
> a bandwidth that we don't have :-/ Some weeks several of us work full
> time on backports and tests! Right now we've reached a point where
> backports can prevent us from working on mainline, and where this lack
> of time increases the risk of regressions, and the regressions require
> more backport time.
Wouldn't this mean there are too many versions in parallel?
> I think that the real problem arrives when a version becomes generally
> available in distros. And distro users are often the ones with the least
> autonomy when it comes to rolling back. When you build from sources,
> you're more at ease. Thus probably that a nice solution would be to
> add an idle period between a stable release and its appearance in
> distros so that it really gets some initial deployment before becoming
> generally available. And I know that some users complain when they do
> not immediately see their binary package, but that's something we can
> easily explain and document. We could even indicate a level of confidence
> in the announce messages. It has the merit of respecting the principle
> of least surprise for everyone in the chain, including those like you
> and me involved in the release cycle and who did not necessarily plan
> to stop all activities to work on yet-another-release because the
> long-awaited fix-of-the-month broke something and its own fix broke
> something else.
We can do that. In the future, I may even tackle all the problems at
once: providing easy access to old versions and have two versions of
each repository: one with new versions immediately available and one
with a semi-fixed delay.
--
April 1
This is the day upon which we are reminded of what we are on the other three
hundred and sixty-four.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
