From Fedora Project Wiki
(Bumped to match newest version of this document)
(Tried to clean this up a bit)
Line 1: Line 1:
= Ideas for implementing the Boards stable updates vision =
This page collects ideas for implementing the Fedora Board's [[stable release updates vision]]. Ideas should be added under the applicable category. Each idea should specify the targeted release: Fedora 14, Fedora 15, or Fedora 15+.


Note ideas under each of the vision statement lines that apply to it.
== Stable releases ==


Note if your idea should be targeted at before f14, by f15, or "later"
=== High-quality updates ===
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 ==
* ''Fedora 14'': Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.


*# BY-F14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.  
=== Consistent user experience ===
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 ==
* ''Fedora 14'': Document this stance in maintainer docs and announce to maintainers the new docs.
* ''Fedora 14'': release managers for each release to monitor updates and educate maintainers?
* ''Fedora 14'': Document a exception process. Some packages will need to provide updates for security reasons or working with external sources, etc.


*# BY-F14: Document this stance in maintainer docs and announce to maintainers the new docs.
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: 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 ==
* ''Fedora 14'': Some way of noting when someone builds an update for all branches at the same time to allow for further scrutiny?


*# BY-F14: Some way of noting when someone builds an update for all branches at the same time to allow for further scrutiny?
== Repositories ==


== Close tracking of upstream should be done in the Rawhide repo wherever possible, and we should strive to move our patches upstream ==  
=== Rawhide ===


*# BY-F15: track the upstream status of patches. Is the trend improving over time? can we help packages with many patches somehow?
Close tracking of upstream should be done in [[Rawhide]] wherever possible, and we should strive to move our patches upstream.


== 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 ==
* ''Fedora 15'': track the upstream status of patches. Is the trend improving over time? can we help packages with many patches somehow?


*# BY-F14: more press for fedora-easy-karma somehow?
More skilled and/or intrepid users are encouraged to use Rawhide along with participating in testing of stable branches during the development and prerelease period.


== 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 ==
* ''Fedora 14'': more press for fedora-easy-karma somehow?


*# BY-F14: metrics on how many updates each branch gets including rawhide?
=== Graduated approach ===


== 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 ==
Stable releases, prerelease branches, and Rawhide repositories should have a graduated approach to what types of updates are expected. For example, a prerelease 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 prerelease


*# LATER: Some kind of monthy report (or script that generates report on demand) of the above items in one place?
* ''Fedora 14'': metrics on how many updates each branch gets including rawhide?


== Add an additional optional repository for feature updates ==
=== updates-features ===
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.   
* ''Fedora 14'': 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.
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.
== Measurement & quality assurance ==
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
* ''Fedora 15+'': Some kind of monthly report (or script that generates report on demand) of the above items in one place?

Revision as of 05:03, 6 July 2010

This page collects ideas for implementing the Fedora Board's stable release updates vision. Ideas should be added under the applicable category. Each idea should specify the targeted release: Fedora 14, Fedora 15, or Fedora 15+.

Stable releases

High-quality updates

The update repositories for stable releases of the Fedora distribution should provide our users with a consistent and high quality stream of updates.

  • Fedora 14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.

Consistent user experience

Stable releases should provide a consistent user experience throughout the lifecycle and only fix bugs and security issues.

  • Fedora 14: Document this stance in maintainer docs and announce to maintainers the new docs.
  • Fedora 14: release managers for each release to monitor updates and educate maintainers?
  • Fedora 14: 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.

  • Fedora 14: Some way of noting when someone builds an update for all branches at the same time to allow for further scrutiny?

Repositories

Rawhide

Close tracking of upstream should be done in Rawhide wherever possible, and we should strive to move our patches upstream.

  • Fedora 15: 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 prerelease period.

  • Fedora 14: more press for fedora-easy-karma somehow?

Graduated approach

Stable releases, prerelease branches, and Rawhide repositories should have a graduated approach to what types of updates are expected. For example, a prerelease 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 prerelease

  • Fedora 14: metrics on how many updates each branch gets including rawhide?

updates-features

Add an additional optional repository for feature updates

  • Fedora 14: 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.

Measurement & quality assurance

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

  • Fedora 15+: Some kind of monthly report (or script that generates report on demand) of the above items in one place?
Retrieved from "https://fedoraproject.org/w/index.php?title=User:Dafrito/Stable_release_updates_vision_implementation_ideas&oldid=184496"