(Created page with '= 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 ...') |
No edit summary |
||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{admon/important|DRAFT|This is only a draft at this time. The content needs to be discussed, refined, and agreed upon by the Fedora Project, and reconciled with the [[Board|Board's]] [[Stable release updates vision]], before an action is taken on the content within.}} | |||
{{admon/warning|Largely Historic|This document is a proposal archived for history. The current policy is at [[Updates Policy]].}} | |||
= Background = | = 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. | 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. | ||
| Line 7: | Line 12: | ||
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. | 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 | Once a Fedora release has been completed and published, updates for it are released under a variety of circumstances, which all must follow the [[Stable_release_updates_vision#Vision_Statement | Stable Release 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 [https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html 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. | Updates offered by our built-in tools under the auspices of the Fedora Project are seen as authoritative by users. While a user fitting [https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html 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. | ||
== Why == | == Why == | ||
| Line 25: | Line 23: | ||
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. | 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 | ''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 == | == 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. | 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. | ||
When preparing updates it is important to consider not just what type of update is being issued, but also who will be impacted by the updates. Both users of the updates and maintainers of packages which might need to be rebuilt for your update. The larger the impact the more careful the update must be treated. | |||
=== High-impact bugfixes === | === High-impact bugfixes === | ||
| Line 51: | Line 53: | ||
* upstream supports micro-version updates to stable upstream releases | * upstream supports micro-version updates to stable upstream releases | ||
* upstream has a sufficiently high level of regression testing for their stable releases | * upstream has a sufficiently high level of regression testing for their stable releases | ||
* upstream has a solid track record for high quality micro updates without regressions | |||
* regression tests are enabled in the package's build | * regression tests are enabled in the package's build | ||
| Line 66: | Line 69: | ||
# have an obviously safe patch and | # have an obviously safe patch and | ||
# affect an application rather than critical infrastructure packages (like X.org or the kernel). | # affect an application rather than critical infrastructure packages (like X.org or the kernel). | ||
=== New Packages === | |||
New packages which have never been in a Fedora release before are an acceptable update. Please be aware that while the package is new, there is still risk of things not found during package review including: | |||
* Improper (auto)provides/requires | |||
* Improper obsoletes | |||
* File conflicts | |||
=== Language Repository Updates === | |||
Something about cpan and the like here FIXME | |||
=== New Upstream Versions === | === New Upstream Versions === | ||
Latest revision as of 21:07, 12 March 2015
This is only a draft at this time. The content needs to be discussed, refined, and agreed upon by the Fedora Project, and reconciled with the Board's Stable release updates vision, before an action is taken on the content within.
This document is a proposal archived for history. The current policy is at Updates Policy.
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 Stable Release 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.
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.
When preparing updates it is important to consider not just what type of update is being issued, but also who will be impacted by the updates. Both users of the updates and maintainers of packages which might need to be rebuilt for your update. The larger the impact the more careful the update must be treated.
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
- upstream has a solid track record for high quality micro updates without regressions
- 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 Packages
New packages which have never been in a Fedora release before are an acceptable update. Please be aware that while the package is new, there is still risk of things not found during package review including:
- Improper (auto)provides/requires
- Improper obsoletes
- File conflicts
Language Repository Updates
Something about cpan and the like here FIXME
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.