Todo Discuss at BRNO and FLOCK and gather intel for concrete community proposal
Fedora as a platform... Flexible release cycle for sub-community which would allow various sub-community align with their upstream ( Gnome to gnome upstream kde to kde upstream etc ) Benefits of rebase policy for the entire components that make up the base/core OS ( feature available to users,less maintainership overhead etc Fedora becoming first again )? Come up with a release strategy of the base/core OS to be the future platform other sub-community build upon? Come up with a QA testing policy which covers the base/core OS as an platform which should cover it from rawhide --> F-GA1 --> F-GA2? Upstream stable release cycle, dracut does not have one systemd does not have one perhaps just the kernel? Should we have one stable base/core OS release and another one ever moving forward? Ask Harald about aligning the dracut release cycle with systemd one since they are so coupled together these days? Kernel releases average ca 4 per year Systemd has ca 7 weeks on average between release and ca four per year for distribution to (re)base upon Dracut has ca four releases per year which also might mean four rebases util-linux has ca 2 stable releases per year .... Should the base/coreOS re-base policy be based on the kernel releases, new kernel release == new base/coreOS platform release upstreams might be require to align their ( stable ) release cycle to an kernel one For Fedora it might mean 3 or 4 base/core os rebases per release,per year with backports between rebases? Flammable community topic which components is the base/coreOS made up of ( should we keep it strictly base/coreOS or base/coreOS + X/Wayland )
DRAFT Systemd Rebasing
During a Fedora release's lifetime, systemd is often rebased to the most recent stable version. A release might ship with e.g. systemd 200 and then be rebased to systemd 201 shortly thereafter. There are a few reasons systemd maintainers do this, and this page will hopefully explain why and how we use this method of systemd maintenance in Fedora.
Why rebase?
Basically, if we don't keep the systemd on at least a somewhat recent upstream release the amount of work required to support that release grows beyond what we can realistically maintain in addition to be cherry picking and backporting patches new features will also have to be patched out.
Let's use F17 as an example. Fedora 17 shipped with the systemd release 44. The stable series went EOL upstream a couple of months after F17 shipped, which means that there was no more upstream maintenance on it at all. No auto-backports, no security fixes, nothing. If we were to stick with 44 for the entirety of F17, the Fedora systemd maintainers would have roughly another year and a half of using a systemd release that upstream absolutely did not care about. They would need to weed through all of the commits that went into 20x (until it goes EOL ) to figure out which fix security issues, which fix issues that hit enough people to warrant a backport, etc. Then they would need to backport them which starts out easy enough but as time goes on becomes increasingly difficult.
The rate of change in the upstream systemd is extremely fast paced so once the upstream systemd becomes a couple of releases removed from what Fedora is using the "simple" fixes are heavily dependent on code changes and subsystem reworks that went in prior to that.
By rebasing the Fedora systemd frequently, we limit the amount of work required to actually fix issues that our users see. Fedora also gets new feature enablement from the newer systemd, and new features. Perhaps most importantly, Fedora stays relevant to upstream so that when bugs are found the upstream developers typically still have the changes that went into that systemd fresh in their memories. That is very important as we work with upstream to provide fixes for the bugs. If systemd is "stale" in the eyes of the upstream developers, we tend to get much less participation.
How are rebases done?
This will focus on rebases within stable releases. Rawhide is continuously being rebased to the latest upstream git kernel and that is fairly expected for that repository.
A typical stable Fedora release rebase follows a fairly set pattern. The systemd will remain on the upstream release that it originally shipped with (e.g. 20X) until upstream announces good release to synchronize a distribution on. At that point in time the Fedora systemd maintainers will rebase the newest good synchronized release and submit an update into updates-testing. Once that update has gone through the normal Fedora update process and received enough karma to be pushed to the stable updates repository, the maintainers wait a bit longer and evaluate how well that new systemd release is working for the majority of those users.
If the new update seems to be working well and does not introduce a large number of regressions, the Fedora systemd maintainers will typically rebase the oldest stable Fedora release as well and repeat the process. This is done to minimize the number of different systemd releases the team is supporting at one time. The maintainers exercise a bit more caution when rebasing the oldest stable release in an attempt to follow the update guidelines as best as possible. In the last few weeks of that release, a rebase might be skipped and only important security fixes will be backported.
Frequently Asked Questions
Does this mean you don't backport things at all?
No, the Fedora systemd maintainers do backports all the time. We backport fixes, security issues, etc. However, by rebasing frequently we're only having to do that from usually one release away which also allows for new features to be introduced to older releases instead of being patched out.
Why does not systemd have a stable long support releases and we ship that?
Systemd announces only release that are good for distribution to synchronize on but does not have long term support release cycles however when dealing with stable release cycle on components which have long support releases, regardless who those components are they don't often work out. The first is that each Fedora release brings a certain component release at GA time and Fedora schedule rarely coincide with a fresh stable long support releases being announced upstream. Remember, "First" is one of Fedora's four Fs. We do use the normal systemd releases very heavily, but those are short term.
The second reason the aren't used is that the majority of them are fairly poorly maintained after a while. Fedora 17 was stuck with the systemd-44.x and towards the end of F17's lifetime that was an exercise in frustration. It is rare that enough upstream developers care about a systemd to truly focus on maintaining it. When that happens, it tends to correlate with that particular systemd release being used by a major enterprise distribution basing on it.
Current versions box Have yes/no?
| Release | Version | Comments |
| F19 | 20x | soon to be rebased to 20Y |
| F20 | 20x | soon to be rebased to 20X. |
| F21 | 20x | F21 GA systemd will be 20Z. Soon to be rebased to 20N |
| Rawhide | Latest upstream release | Always the latest upstream tree. |
DRAFT Dracut Rebasing
During a Fedora release's lifetime, dracut is often rebased to the most recent stable version. A release might ship with e.g. dracut 024 and then be rebased to dracut 026 shortly thereafter. There are a few reasons dracut maintainers do this, and this page will hopefully explain why and how we use this method of dracut maintenance in Fedora.
Why rebase?
Given the close relationship with the kernel which already has a rebase policy along with init systemd means that if we don't keep the dracut on at least a somewhat recent upstream release the amount of work required to support that release grows beyond what we can realistically maintain in addition to be cherry picking and backporting patches, new features will also have to be patched out.
Let's use F17 as an example. Fedora 17 shipped with the dracut release 018 . The stable series went EOL upstream a couple of months after F17 shipped, which means that there was no more upstream maintenance on it at all. No auto-backports, no security fixes, nothing. If we were to stick with 018 for the entirety of F17, the Fedora dracut maintainers would have roughly another year and a half of using a dracut release that upstream absolutely did not care about. They would need to weed through all of the commits that went into 029 (until it goes EOL ) to figure out which fix security issues, which fix issues that hit enough people to warrant a backport, etc. Then they would need to backport them which starts out easy enough but as time goes on becomes increasingly difficult.
The rate of change in the upstream dracut is extremely fast paced so once the upstream dracut becomes a couple of releases removed from what Fedora is using the "simple" fixes are heavily dependent on code changes and subsystem reworks that went in prior to that.
By rebasing the Fedora dracut frequently, we limit the amount of work required to actually fix issues that our users see. Fedora also gets new feature enablement from the newer dracut, and new features. Perhaps most importantly, Fedora stays relevant to upstream so that when bugs are found the upstream developers typically still have the changes that went into that dracut fresh in their memories. That is very important as we work with upstream to provide fixes for the bugs. If dracut is "stale" in the eyes of the upstream developers, we tend to get much less participation.
How are rebases done?
This will focus on rebases within stable releases. Rawhide is continuously being rebased to the latest upstream git kernel and that is fairly expected for that repository.
A typical stable Fedora release rebase follows a fairly set pattern. The dracut will remain on the upstream release that it originally shipped with (e.g. 02X) until upstream announces good release to synchronize a distribution on. At that point in time the Fedora dracut maintainers will rebase the newest good synchronized release and submit an update into updates-testing. Once that update has gone through the normal Fedora update process and received enough karma to be pushed to the stable updates repository, the maintainers wait a bit longer and evaluate how well that new dracut release is working for the majority of those users.
If the new update seems to be working well and does not introduce a large number of regressions, the Fedora dracut maintainers will typically rebase the oldest stable Fedora release as well and repeat the process. This is done to minimize the number of different dracut releases the team is supporting at one time. The maintainers exercise a bit more caution when rebasing the oldest stable release in an attempt to follow the update guidelines as best as possible. In the last few weeks of that release, a rebase might be skipped and only important security fixes will be backported.
Frequently Asked Questions
Does this mean you don't backport things at all?
No, the Fedora dracut maintainers do backports all the time. We backport fixes, security issues, etc. However, by rebasing frequently we're only having to do that from usually one release away which also allows for new features to be introduced to older releases instead of being patched out.
Why does not dracut have a stable long support releases and we ship that?
Dracut announces only release that are good for distribution to synchronize on but does not have long term support release cycles however when dealing with stable release cycle on components which have long support releases, regardless who those components are they don't often work out. The first is that each Fedora release brings a certain component release at GA time and Fedora schedule rarely coincide with a fresh stable long support releases being announced upstream. Remember, "First" is one of Fedora's four Fs. We do use the normal dracut releases very heavily, but those are short term.
The second reason the aren't used is that the majority of them are fairly poorly maintained after a while. Fedora 17 was stuck with the dracut-018.x and towards the end of F17's lifetime that was an exercise in frustration. It is rare that enough upstream developers care about a dracut to truly focus on maintaining it. When that happens, it tends to correlate with that particular dracut release being used by a major enterprise distribution basing on it.
Current versions box Have yes/no?
| Release | Version | Comments |
| F19 | 02x | soon to be rebased to 02Y |
| F20 | 02x | soon to be rebased to 02X. |
| F21 | 02x | F21 GA dracut will be 02Z. Soon to be rebased to 03N |
| Rawhide | Latest upstream release | Always the latest upstream tree. |