This page collects ideas for implementing the Fedora Board's stable release updates vision in order to implement the stable release updates proposal. 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?
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.
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?
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?