No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
Come up with a QA testing policy which covers he base/core OS as an platform which should cover it from rawhide --> F-GA1 --> F-GA2? | Come up with a QA testing policy which covers he 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? | Upstream stable release cycle dracut does not have one systemd does not have one perhaps just the kernel? | ||
Should we have circling one stable base/core OS and another one ever moving forward? | Should we have circling one stable base/core OS release and another one ever moving forward? | ||
Ask Harald to align the dracut release cycle with systemd one? | |||
== DRAFT Systemd Rebasing== | == DRAFT Systemd Rebasing== | ||
| Line 13: | Line 14: | ||
=== Why rebase? === | === 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. | 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 | 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 kernel 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 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 kernel is extremely fast paced so once the upstream kernel 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. | 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 kernel is extremely fast paced so once the upstream kernel 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. | ||
| Line 24: | Line 25: | ||
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. | 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 | 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. | 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. | ||
| Line 32: | Line 33: | ||
Does this mean you don't backport things at all? | 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. | 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? | 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 those schedules 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 | 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. | ||
Revision as of 22:08, 16 July 2013
Todo Discuss at BRNO and FLOCK
Benefits of rebase policy for the entire components that make up the base/core OS ( feature available to users,less maintainership overhead etc )? Should the base/coreOS re-base policy be based on the kernel release/rebase policy? 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 he 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 circling one stable base/core OS release and another one ever moving forward? Ask Harald to align the dracut release cycle with systemd one?
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 kernel 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 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 kernel is extremely fast paced so once the upstream kernel 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 those schedules 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.