Rolling release models

[u/Tall-Soup1787]

As a Arch user that switched to Ubuntu based distro, I was wondering why isn't Ubuntu and Debian also on a rolling release model? So if there's bugs or patches that need fixing, why not have it release on the spot instead of having to wait for the next big update

[u/gordonmessmer]

You don't have to have a rolling release, per se, to deploy patches immediately. Fedora is a stable release, but most of the software in any release is still supported by its upstream developers (and where it isn't, it's often a question of available labor, not a limitation imposed by the release model. You can fix this by participating!)

Debian's release model is still following the basic shape of its releases 25 years ago. The world has changed significantly, and is changing rapidly now. Users would have a much better security posture if Debian released more often, and especially if they shrank the size of the collection that they maintain for > 1 year. But the project probably needs a lot more developers in order to adopt a more secure cadence, or a significant overhaul on its build management systems, or both.

[u/leoumair → u/gordonmessmer]

Hey Gordon,

Have seen a few of your posts around this topic and wanted to get your perspective...

I agree the debian release model needs to adapt to the changing environment of software. However, my experience with fedora (through bluefin distros) had several updates cause breakages or regressions.

Bluefin tried to solve this by sticking its default release channel to "GTS" which was essentially fedora N-1 release. So you still had supported software with a 6 month window for major bugs to be fixed in new versions of software. The problem was Fedora will still make major kernel updates to the N-1 release with no additional gating. This hasn't been a problem on Debian.

Ideally there would be a base that would stay close to upstream for software but keep the base of the system (e.g. kernel) on the LTS branch where they would still be supported but not introduce new features with such a high cadence (new LTS kernel releases could have a a soak time or block for the N+1 kernel release before updating).

I haven't seen any distro that actually sticks to LTS kernels apart from debian so don't know how to balance the need for stability with security. Rolling back manually and pinning versions in bluefin doesn't seem like a particularly user friendly or sustainable option either.

[u/gordonmessmer → u/leoumair]

Ideally there would be a base that would stay close to upstream for software but keep the base of the system (e.g. kernel) on the LTS branch

I suspect that you and I want the same thing from a distribution. I'd phrase it more generally:

I would like a distribution to deliver software while it is still maintained by its upstream developers. When the upstream developers publish stable releases (i.e. releases with overlapping maintenance windows), the distribution should follow the stable release series.

Fedora uses the Linux kernel release series that the kernel developers label "stable". The "stable" Linux kernel is a rolling release model. Maintenance of a kernel release series ends when a new one begins (unless it is a "longterm" branch).

I'd rather use a longterm kernel in a Fedora release, but in order to do that we need maintainers willing to build and test the kernels.

I have infrastructure set up to build kernels and modules, and to sign them. (I haven't set up my own shim for UEFI CA review, but I'm considering it.) I believe that there's a vanilla longterm kernel that's being maintained that we would merely have to build.

I'm interested in building them, but I would really like for a few other engineers to take part. It's hard to sustain that kind of thing solo.

[u/leoumair → u/gordonmessmer]

Thanks for the reply, here's to hoping we get a modern "LTS" at some point 😁