From Fedora Project Wiki
(Initial fork of Stable release updates vision implementation ideas) |
(Bumped to match newest version of this document) |
||
| Line 6: | Line 6: | ||
== The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates == | == The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates == | ||
*# BY-F14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing. | |||
== Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues == | == Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues == | ||
| Line 11: | Line 13: | ||
*# BY-F14: Document this stance in maintainer docs and announce to maintainers the new docs. | *# BY-F14: Document this stance in maintainer docs and announce to maintainers the new docs. | ||
*# BY-F14: release managers for each release to monitor updates and educate maintainers? | *# BY-F14: release managers for each release to monitor updates and educate maintainers? | ||
*# BY-F14: Document a exception process. Some packages will need to provide updates for security reasons or working with external sources, etc. | |||
== 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 should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues == | ||
*# BY-F14: Some way of noting when someone builds an update for all branches at the same time to allow for further scrutiny? | |||
== Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream == | == Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream == | ||
*# BY-F15: track the upstream status of patches. Is the trend improving over time? can we help packages with many patches somehow? | |||
== More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period == | == More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period == | ||
*# BY-F14: more press for fedora-easy-karma somehow? | |||
== Stable releases, pre-release branches, and Rawhide have a graduated approach to what types of updates are expected. For example, a pre-release branch should accept some updates which a stable release would not, and rawhide would accept updates that are not appropriate for either a stable release or a pre-release == | == Stable releases, pre-release branches, and Rawhide have a graduated approach to what types of updates are expected. For example, a pre-release branch should accept some updates which a stable release would not, and rawhide would accept updates that are not appropriate for either a stable release or a pre-release == | ||
| Line 24: | Line 33: | ||
== Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements == | == Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements == | ||
*# LATER: Some kind of monthy report (or script that generates report on demand) of the above items in one place? | |||
== Add an additional optional repository for feature updates == | == Add an additional optional repository for feature updates == | ||
Revision as of 04:15, 6 July 2010
Ideas for implementing the Boards stable updates vision
Note ideas under each of the vision statement lines that apply to it.
Note if your idea should be targeted at before f14, by f15, or "later"
The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates
- BY-F14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.
Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues
- BY-F14: Document this stance in maintainer docs and announce to maintainers the new docs.
- BY-F14: release managers for each release to monitor updates and educate maintainers?
- BY-F14: Document a exception process. Some packages will need to provide updates for security reasons or working with external sources, etc.
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
- BY-F14: Some way of noting when someone builds an update for all branches at the same time to allow for further scrutiny?
Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream
- BY-F15: track the upstream status of patches. Is the trend improving over time? can we help packages with many patches somehow?
More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and pre-release period
- BY-F14: more press for fedora-easy-karma somehow?
Stable releases, pre-release branches, and Rawhide have a graduated approach to what types of updates are expected. For example, a pre-release branch should accept some updates which a stable release would not, and rawhide would accept updates that are not appropriate for either a stable release or a pre-release
- BY-F14: metrics on how many updates each branch gets including rawhide?
Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements
- LATER: Some kind of monthy report (or script that generates report on demand) of the above items in one place?
Add an additional optional repository for feature updates
- By=F14: Have an updates-features optional repository. The current updates-testing to updates path would be used for all security and bug fixes. A new updates-features-testing to updates-features will be used for updates that could affect the stability of the release. This will allow inclusion of upstream projects that do not have their releases in sync with Fedora's. These repos would not be enabled by default, but by enabling them the user will be able to use the latest releases of their software without having to run rawhide.
To encourage users to upgrade to the newest releases I suggest these repos be frozen and accept no further pushes once the next release goes into alpha. So for release (n-1) bug and security fixes only, release (n) bug and security fixes throughout its life, feature updates optional, with no new feature updates after (n+1) goes into alpha.