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.
Exceptions for stable updates should fall into one of two categories:
- Packages that are no longer provided with security updates by
upstream and which are too big for backporting fixes to be reasonably practical.
This will be evaluated on a case by case basis, with an exception only being granted where there is genuinely no practical possibility of maintaining security updates within Fedora.
- Packages which require updates in order to maintain functionality
Examples here include virus checkers and games with rapidly evolving protocols. Exceptions in this category will be limited to packages which will become unable to carry out their existing functionality[1] unless updates occur. Updates will not be permitted purely to add additional functionality.
[1] Where existing functionality for a virus checker would be "Find common viruses" rather than "Find this specific set of viruses", and for a game would be "Connect to central servers" rather than "Speak a specific version of the protocol"
Applications for exceptions should be made to FESCO, who will evaluate whether a specific package satisfies either of these criteria. Those that do may be updated during a stable release cycle even if that would otherwise be forbidden.
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?
To date F12 has has the following pushed to the stable repository.
220 Security fixes 1049 Enhancements 2840 Bug fixes
F13 to date has had the following
114 Security fixes 818 Enhancements 2569 Bug fixes
Even though F13 was only released 2 months ago its numbers are already close to what F12 has received over the past 8 months. I believe this is a result of the earlier branching with No Frozen Rawhide.
We need to define what is an enhancement and what is a bug fix. How many of these updates labeled as bug fixes contained new or updated features.
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.