This is only a draft at this time. The content needs to be discussed, refined, and agreed upon by the Fedora Project before an action is taken on the content within.
Background
There has recently been lots of threads about how updates in Fedora should work. There have been a number of proposals thrown about, some dealing with how things get into stable, and some dealing with what kinds of updates we should do. FESCo is currently considering how things get into stable, while the board is working on what kind of updates we should do.
I am writing this proposal to focus on what kind of updates we should do.
Proposal
A Fedora release is a cohesive set of package versions that has been integrated and tested to work well as a whole. It is expected that this cohesive set will not drastically change during the lifetime of the release in order to provide a stable platform for use. A shifting platform and visible behavioral changes will affect the user's productivity because the user must take time away from the desired tasks to discover what has changed, adjust the way they perform supporting tasks, and refocus on their original objectives. Because productivity is postulated as important to our users, this outcome is undesirable. Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks.
Once a Fedora release has been completed and published, updates for it are released under a variety of circumstances, which all must follow the update vision. The types of updates allowed are listed below. Updates outside the cases listed are strongly discouraged. It is up to the package maintainer to review the change (s)he wishes to make and measure it against the vision and update types to make a decision if the update should be issued or not. In all update cases, an update which will require multiple other packages to be rebuilt and updated should be undertaken with extreme caution.
Updates offered by our built-in tools under the auspices of the Fedora Project are seen as authoritative by users. While a user fitting the broad criteria is likely to file a bug when something goes wrong, the user does not therefore automatically expect new issues to emerge in a stable release as a result of consuming those updates. When such issues do emerge, the user's confidence in the platform is undermined.
Vision
- The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality series of updates.
- Stable releases should provide a consistent user experience throughout the lifecycle, and generally only fix bugs and security issues.
- Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues.
- Stable releases, pre-release branches, and Rawhide should have a graduated approach to ease of updating. For example, if a proposed update does more than fix a bug or security issue, it should be harder to push that update to a stable release than to a pre-release branch or Rawhide.
Why
In contrast to pre-release versions, official releases of Fedora are subject to much wider use, and by a different demographic of users. During development, changes to the distribution primarily affect developers, early adopters and other advanced users, all of whom have elected to use pre-release software at their own risk.
Users of the official release, in contrast, expect a high degree of stability. They use their Fedora system for their day-to-day work, and problems they experience with it can be extremely disruptive. Many of them are less experienced with Fedora and with Linux, and expect a reliable system which does not require their intervention.
Stable release updates are automatically recommended to a very large number of users, and so it is critically important to treat them with great caution. Since every change represents some level of risk, when updates are proposed they must be accompanied by a strong rationale and present a low risk of regressions.
More skilled and/or intrepid users seeking a more rapid delivery of updates are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period. Branched repos are made available within 2 to 3 months of a stable Fedora release and should provide a more tested (but still rapid) stream than Rawhide, should Rawhide be too unstable.
What Kind of Updates
The Fedora user base is vast and varied, as is the package set. The type of updates we issue do vary by packages and by expected users. This section illustrates a number of update varieties, and hopes to provide some logical grouping of update types that might need different mechanisms or requirements to move out of -testing and into -stable.
High-impact bugfixes
These are the most important updates Fedora can issue. They can effect a wide range of users, or have very disastrous impact. These types of bugs include:
- Bugs which may, under realistic circumstances, directly cause a security vulnerability. These are governed by the Security team and documented elsewhere.
- Bugs which represent severe regressions from the previous release of Fedora or a previous Stable Release Update. This includes packages which are totally unusable, like being uninstallable or crashing on startup or during normal expected operation.
- Bugs which may, under realistic circumstances, directly cause a loss of user data
- Bugs which prevent software from working with external data / service providers
Generally it is expected that these types of bugs can be fixed without introducing new major upstream releases. When this is not the case the update should be considered a new upstream version and treated accordingly.
New Hardware Enablement
Such changes are appropriate provided that we can ensure to not affect upgrades on existing hardware. For example, enabling support for new graphics cards within a family should not come at the cost of regressing existing supported cards in the same family.
Micro Version Updates
For some packages it is acceptable to upload new upstream microreleases to stable Fedora releases. The following criteria explains:
- upstream supports micro-version updates to stable upstream releases
- upstream has a sufficiently high level of regression testing for their stable releases
- regression tests are enabled in the package's build
Regular Data Updates
Some packages offer regular data updates without altering functionality. This type of data might include:
- Antispam data
- Antivirus definitions
- Timezone Data
Targeted Application Updates
- Bugs which do not fit under above categories, but
- have an obviously safe patch and
- affect an application rather than critical infrastructure packages (like X.org or the kernel).
New Upstream Versions
For new upstream versions of packages which provide new features, but don't just fix critical bugs, an update can still be issued, but it is vital that the new upstream version does not regress or drastically change a user's experience.