Fedora Lifecycles: imagine longer-term possibilities!

lifecycle
schedule
fedora-30

#1

Hi everyone! Let’s talk about something new and exciting. Since its first release fifteen years ago, Fedora has had a 13-month lifecycle (give or take). That works awesomely for many cases (like, hey, we’re all here), but not for everyone. Let’s talk about how we might address some of the users and use cases we’re missing out on.

When I talk to people about this, I often get "hey, you should do LTS or go to rolling releases.” As I’ve said before, on the surface that’s a weird thing to say, since the actual user impact of those two different things is mostly opposite. So, digging in, it often really means “I don’t want the pain and fear of big OS upgrades”.

We’ve addressed that in several ways: first, making upgrades better. (Thanks everyone who has worked on that.) A Fedora release-to-release update is normally not much more trouble than you might get some random Tuesday with a rolling release. Second, we have some things like Fedora Atomic Host and upcoming Fedora CoreOS and IoT which both implement a rolling stream on top of the Fedora release base. And finally, there’s the coming-someday plans for gating Rawhide, making that a better proposition for people who really want to live on the edge.

But there are some good cases for a longer lifecycle. For one thing, this has been a really big blocker for getting Fedora shipped on hardware. Second, there are people who really could be happily running Fedora but since we don’t check the tickbox, they don’t even look at us seriously. I’d love to change these things. To do that, we need something that lasts for 36-48 months.

So, what would this look like? I have some ideas, but, really, there are many possibilities. That’s what this thread is for. Let’s figure it out. How would we structure repositories? How would we make sure we’re not overworked? How would we balance this with getting people new stuff fast as well?


#2

IMHO it’s pretty simple: a desktop rolling release Silverblue, and LTS for CoreOS / server / cloud. Silverblue’s sort of already rolling, since you can run anything in a container - Flatpaks, Gentoo, Tumbleweed, three different releases of PostgreSQL, Arch, Fedora with software built from source, etc.

And people who run servers generally run either Ubuntu LTS, of which there are three, or RHEL/CentOS. Fedora’s rare in that space.


#3

@mattdm which plans have you for Silverblue? Rolling, just another experimental release or default in near future?

Fedora LTS with the 3 years cycle will be great and beats Ubuntu 'cause 4-5 years are too big time for modern web technologies. For anything else - just switch to Centos/RHEL.


#4

To be honest, I would look into the original concept of modularity again and target it as original goal. The idea to have stable platform and build modules on top of it is the ideal state for me. There are many challenges with this, like installing multiple streams of same thing is MUST (I can’t really modularize Rust stuff because 1) MBS/Koji is too slow 2) Installing multiple streams is not a thing). We need some transition period which would allow us having modular platform but also use it in buildroot (this is where I’m still waiting for Ursa Major).

However, this would definitely require help from all maintainers, not just few geeks from Modularity WG.

If we reach this state, we will be allowing users to choose some stable Platform (CentOS one, for instance) and still having apps built on top of that. And if we make it easy to deploy build infra outside of Fedora, people will build their own platforms as they need.


#5

Igor can you elaborate on why installing multiple streams in parallel is crucial?


#6

For Rust or in general?

In former case you mind end up with 2 (or even 3-4) versions of same crate in buildroot (usually because dependencies are not ported to latest version while your app does). Sometimes it is essential because depending on same version breaks your binary — https://github.com/rust-lang/cargo/issues/2589.

And in general, just simple example:

⋊> ~/P/u/rust2rpm on master ⨯ rpm -qR beignet | grep LLVM                                                                           14:56:33
libLLVM-6.0.so()(64bit)
libLLVM-6.0.so(LLVM_6.0)(64bit)
⋊> ~/P/u/rust2rpm on master ⨯ rpm -qR mesa-dri-drivers | grep LLVM                                                                    14:56:42
libLLVM-7.so()(64bit)
libLLVM-7.so(LLVM_7)(64bit)

If I want to use beignet, that would mean that I need to uninstall mesa-dri-drivers which would result in broken system (I mean no graphics).

Another example might be python interpreters, right now we allow all python2 and python3 versions to be installed at the same time which helps developers to run tox and test their library against all python versions. It is essential to support their workflow.


I understand that we don’t want to allow all streams of all modules enabled at the same time (because it is insane), but we should allow doing so in easy way for case by case (not creating llvm6:6, llvm7:7 modules and such.


#7

That brings up another question in my mind. It used to be the case that packages moved from Fedora into RHEL and then got recompiled to make CentOS. IIRC RHEL 7 was built from the packages in Fedora 19, and then evolved independently from there.

That was something like five years ago. RHEL / CentOS 7 are still going strong in their user base, but Fedora seems to have diverged significantly. There are many more versions of Fedora than RHEL. I don’t know anyone who runs a RHEL or CentOS desktop. And for a while there were three versions of Atomic Host, RHEL, CentOS and Fedora.

I wonder if one can fully contemplate the future / direction of Fedora without knowing at least a little bit about the road map for RHEL. Is RHEL 8 going to show up based on Fedora 30 or a later version? There’s some good stuff in Fedora that’s not in RHEL.


#8

Hi. The question is intended/destined to Silverblue group? or the whole community? because this is a closed group focused on Silverblue; we should change the name to “Fedora Silverblue discussion”; I am sorry but it is the reality … I will try not to mix several disagreements and avoid mistreat them.

Well; I will to be objective; Fragmentation destroys; We are guinea pigs; or are we users?

The efforts could be exploited in a “Rolling Release” model; to reduce resources and improves the product. LTS is a good idea, but not the panacea; Fedora will support outdated packages? then modularity is a good option, hand in hand with COPR. Similar to the distribution of a popular philanthropist.

The point is; Is useful maintain various versions of a package? it is a waste of time even for maintainers … therefore a “Rolling Release” is a way to avoids fragmentation and waste of time. People wants install a cloud version, well, install “dnf install group cloud” The people want to experiment as Silverblue, well, install “dnf group install silverblue”; easy no?

For me; flatpaks, with all due respect, I am not a follower of it. Filling my PC with the same software, software with errors not existing in rpm packages … I do not find it useful… But everyone is free to choose their destiny.

Other. the kernel release model should change; maintain an LTS model. When I detect a kernel update; I sweat like a dog in a Chinese restaurant, because my “broadcom dkms” driver could fail; like my nvidia video card in my job. I hope someone does not jump, but Manjaro has a good option to choose the desired kernel and maintain a compatibility rhythm… Returning to the main point, Rolling Release is a model that even makes Google successful.


#9

Hi. The question is intended to Silverblue group? or the whole community? because this is a closed group focused on Silverblue; we should change the name to “Fedora Silverblue discussion”; I am sorry but it is the reality … I will try not to mix several disagreements and avoid mistreat them.

Errr, what? No. This is a general site for Fedora discussion. There is a Silverblue category. This post is in the “Project Conversations” category and is not specific to Silverblue.


#10

The Discourse web interface can be very confusing, so it is certainly
understandable for this mistake to be made.


#11

Probably also because this discussion platform is primarily advertised on the Silverblue site thus far?


#12

Silverblue is a completely different way of managing your base system, so a command like this wouldn’t really work…

If you’re referring to Chrome OS, it’s a very different beast from a standard Linux distro…


#13

There are three main true rolling releases: Gentoo and its derivatives, which is mostly built from source on your machine, Arch Linux and its derivatives, and openSUSE Tumbleweed. I don’t know of anyone who runs a bare-metal server using Arch or a derivative of Arch, or using openSUSE Tumbleweed. I’m sure there are people, but the economics don’t pencil out.

There are people who run Gentoo on bare-metal servers, although not a large number. So if you’re looking for a model of successful servers on a rolling release, I’d hunt down a Gentoo shop.

I don’t think there’d be much of a market for a Fedora rolling release server; people want a long-term support model like Ubuntu LTS, RHEL / CentOS, and Debian Stable. They want something that’s popular, so they can easily find solutions to problems with Google and easily hire experienced DevOps engineers.

It costs time and money to test upgrades, and scheduled interruptions are another cost for deployment. So unless there’s a newly-patched security hole, there’s little incentive to upgrade a server.


#14

I think you’ve moved a little away from the subject, relating Silverblue, that’s not the case.

I am speaking about the fragmentation and waste of time with multiple versions of Fedora and packaging; and the focus on a rawhide model …

“A different way of managing your base system” Sure, then what can said you about these question ¿ H264 codecs on Chromium? if you are using rpm thirdparty repositories. The project still dependent on rpms and the use of dnf …

rpm-ostree is a hybrid image/package system. It uses libOSTree as a base image format, and accepts RPM on both the client and server side, sharing code with the dnf project; specifically libdnf.

We should take a look at Nix; and see their maturity; what I imagine Silverblue wants.

Other, In Silverblue are trying to replace critical parts of the system with a few commands; Wen you update/replace “A” program you must recompile dependent packages (b, w…z), if there is a jump in a “.so” or the path was changed. In rpm packaging some times a package requires a massive rebuild. It is inevitable even in “Silverblue”

I do not see differences; simply an adequate graphical interface; where the user only has access to some parts, unless you enable root . I mention Google because the Rolling release model works for them. If, it is not a standard linux; It is other discussion.

In the end, what it all comes down to is this:

The rolling release model makes our life a little bit easier.

This is because the less time it takes to maintain your operating system, the more time we have for things in life that matter.


#15

You could give Rawhide two branches, which modularity would make easier to achieve.

There’d be a developmental branch which includes pre-release releases of the kernel (e.g. 4.20.0-0.rc2.git0.1.fc30 is what my Rawhide install is presently using) and GNOME (e.g. 3.31.2 is what my Rawhide install is using), which is what Rawhide presently does, and a bleeding branch, which features largely the same software, except without pre-release (or developmental) releases of software like the kernel and GNOME, only the latest stable releases (e.g. 4.19.2 is the latest stable kernel, 3.30.2 is the latest stable GNOME).

Keeping the software up-to-date could be automated using bots/scripts, with humans only getting involved when a package fails to build or a runtime bug is encountered. Given the number of packages in Fedora’s repos, I’d imagine something like this is already going on (correct me if I’m wrong).

The bleeding branch would be for people like me, that like rollers, but don’t want the level of bugs that comes with developmental software. The developmental branch would be largely for Fedora developers and the odd courageous and curious person. Those that wish a mixture of bleeding-edge software with a little extra stability would go for stable Fedora releases. If they want a pinch more bleeding-edge, without taking the leap to rawhide, they can enable ‘testing’ repositories.

As for LTS releases, well frankly I suggest people should go look at CentOS/Oracle Linux/RHEL/Scientific Linux for that. Fedora is pretty much synonymous with cutting-edge software, which I think might be why so many developers (including Torvalds) seem to use it.


#16

$ rant begin
I know this is a cliche, but how is a 36-48-month life cycle for Fedora “skating where the puck is going to be?” How would a 36-48-month Fedora be better than RHEL/CentOS?

You want a vendor to ship Fedora on a laptop? Have the IBM CEO close a sale with the CEO of a hardware vendor! Have it be a priority with a bonus attached for getting it done. Have attorneys and accountants to show it’s a win-win.

Get marketers to show why it’s better than a Dell XPS with Ubuntu. Get enough feedback from real paying customers to know there’s a market and then get a team of engineers to fit the product to that market. The reason there’s a Dell XPS with Ubuntu on it is that Canonical and Dell executives agreed there was a business case to build and market it, not that Ubuntu is “better” than Debian or RHEL or Fedora or any flavor of SUSE.

I think “where the puck is going to be” is Silverblue / podman / Kubernetes / CoreOS / Flatpak. The only thing that’s keeping me off of Silverblue now is two devices - a USB WiFi adapter and an NVidia GPU - that don’t work yet.

I deployed a Docker app on Digital Ocean with the Atomic Host image they have and it was a slam-dunk. Everything just worked. I’m so fed up with the Docker for Windows unfixed bugs and terrible documentation that I’m seriously considering learning enough PowerShell to make the equivalent using Atomic Host in Hyper-V. That’s where the puck is going to be.
$ rant end


#17

[quote=“mattdm, post:1, topic:690”]
But there are some good cases for a longer lifecycle. For one thing, this
has been a really big blocker for getting Fedora shipped on hardware.
Second, there are people who really could be happily running Fedora but
since we don’t check the tickbox, they don’t even look at us seriously. I’d
love to change these things. To do that, we need something that lasts for
36-48 months.
[/quote]

$ rant begin
I know this is a cliche, but how is a 36-48-month life cycle for
Fedora “skating where the puck is going to be?” How would a
36-48-month Fedora be better than RHEL/CentOS?

You want a vendor to ship Fedora on a laptop? Have the IBM CEO close a sale
with the CEO of a hardware vendor! Have it be a priority with a bonus
attached for getting it done. Have attorneys and accountants to show it’s a
win-win.

Get marketers to show why it’s better than a Dell XPS with Ubuntu. Get
enough feedback from real paying customers to know there’s a market and
then get a team of engineers to fit the product to that market. The reason
there’s a Dell XPS with Ubuntu on it is that Canonical and Dell executives
agreed there was a business case to build and market it, not that Ubuntu is
“better” than Debian or RHEL or Fedora or any flavor of SUSE.

I think “where the puck is going to be” is Silverblue / podman / Kubernetes
/ CoreOS / Flatpak. The only thing that’s keeping me off of Silverblue now
is two devices - a USB WiFi adapter and an NVidia GPU - that don’t work
yet.

I deployed a Docker app on Digital Ocean with the Atomic Host image they
have and it was a slam-dunk. Everything just worked. I’m so fed up with the
Docker for Windows unfixed bugs and terrible documentation that I’m
seriously considering learning enough PowerShell to make the equivalent
using Atomic Host in Hyper-V. That’s where the puck is going to be.
$ rant end


[Visit
Topic](https://discussion.fedoraproject.org/t/fedora-lifecycles-imagine-lon
ger-term-possibilities/690/16) or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click
here](https://discussion.fedoraproject.org/email/unsubscribe/84384b1267ec65
76aeca682b7ff15af948b7afca3a7e93556ac17c7211d6c0f5).

Indeed. Additionally, longer lifecycles wouldn’t help to get hardware vendors
to pick up Fedora. They’d just need to update the images they’re throwing out
once every 6 months. That’s not a lot to ask. Does that mean there would be
systems out there with old versions of Fedora? Probably, almost definitely.

EOL only occurs nearly a year after a release, and at those point those
systems can certainly still be updated, even through those GUIs the DEs have.


#18

I don’t know for a fact that Red Hat or SuSE didn’t try to sell Dell on the idea of a supported Linux laptop as a product for sale to end users. Nor do I know for a fact that Dell didn’t say, “Let’s make a Linux laptop”, do a little research on popularity, discover that Ubuntu was far and away the most popular, pick up the phone to Canonical and initiate discussions of a partnership.

What I do know is that there must be some kind of partnership between the “brands” for the XPS with Ubuntu to exist as a commercial product. You at least have to do all the trademark legwork and market viability assessment if nothing else.

You can buy laptops with Linux on them - some prefer to ship one distro but most will load any Linux you want on them and will also load Windows if you pay for it. But they aren’t Dell.

But you know what? They aren’t IBM, either. Red Hat is part of IBM now, and I think IBM could sell a really top-notch laptop with “36-48-month-life-cycle-Fedora Workstation” on it, but with Red Hat or IBM branding. Or create a new brand. I don’t think an open source / foundation-governed Linux distro can compete with a Dell / Ubuntu XPS. IBM / Red Hat probably can.


#19

We already have an LTS. At least two of them. RHEL and CentOS.
A rolling release would be fantastic, but redundant with Fedora’s regular point-realease/upgrade cycle;;; that’s okay, the current release cycle is silly and may as well be rolling.


#20

If you want rolling release, you can run Rawhide. It’s actually fairly stable.