Edit

The Problem to be Solved

Too fast vs. too slow

Different users have different needs. Developers want the latest versions possible, system administrators want stability for longer period of time. There are many Linux distributions out there, each targetting a different audience. A good example is Fedora and CentOS.

Fedora ships the latest greatest and releases a new version twice a year. That is convenient for desktop users and developers. Even though many people use Fedora on a server, it is sometimes necessary to have a stable version of certain packages for a longer time, mostly because of third-party applications.

At the same time, some people consider fedora too slow for them and want even newer runtimes on their system. Some upstreams release their software faster than twice a year.

On the other hand, CentOS targets long-term stability and releases a new version once every few years. This is convenient for server admins as there are less changes over longer periods of time. But some of the software gets old for modern applications and newer versions of runtimes might be needed.

In other words, it would be convenient to be able to choose some parts of the system to be slow, and other parts to be fast. Could we do that?

Outdated containers

There are many containers out there. Majority of them are built manually, not actively maintained, not patched with security fixes, and still used by many people. This is especially true for the ones having software in a different version than the distribution provides.

If Fedora had multiple versions of software that is actively maintained and built, could we use it to produce containers? Could these containers get automatically rebuilt every time the packages get updated?

Complex packager workflows

Fedora contributors maintain their packages in multiple branches — one for each release. Even when the packages are the same. And there is a series of manual steps associated with the build process.

Could we enable packagers to maintain packages in branches that would map the package version instead of an arbitrary distribution release? Having a single branch that builds across multiple releases would save some work for packagers.