(Created page with '{{subst:Proposal}}') |
No edit summary |
||
| Line 2: | Line 2: | ||
== Overview == | == Overview == | ||
Define a "Critical Path" set of packages that require special care when updating in rawhide and releases. | |||
=== Problem Space === | === Problem Space === | ||
<!-- Describe the problem this proposal seeks to solve --> | <!-- Describe the problem this proposal seeks to solve --> | ||
Currently documented policies treat every package the same. While this is good for uniformity, in reality certain packages require and have been given extra attention and care when updating and testing. These packages have potential to break the critical path of use of our Fedora distribution. | |||
=== Proposed Solution === | === Proposed Solution === | ||
<!-- Describe proposed solution in detail --> | <!-- Describe proposed solution in detail --> | ||
Define a set of actions and their packages/deps to provide those actions that to define the "Critical Path". Packages within the "critical path" have extra requirements on getting tagged for freeze breaks and updates. | |||
=== Scope === | === Scope === | ||
<!-- Describe the scope of any project work or properties that will be affected by the proposal --> | <!-- Describe the scope of any project work or properties that will be affected by the proposal --> | ||
* Maintainers of packages within the Critical Path | |||
* QA/Releng to provide extra attention to update/freeze requests for packages within the critical path | |||
* Bodhi to handle extra requirements | |||
* Tooling to define Critical Path each release | |||
* Documentation | |||
=== Active Ingredients === | === Active Ingredients === | ||
<!-- A list of any prerequisites or other materials needed to implement the solution --> | <!-- A list of any prerequisites or other materials needed to implement the solution --> | ||
Bodhi is the most active ingredient here. It will have to handle blocking the update packages within the critical path until it gets the extra attention from QA/releng | |||
== | == Discussion Points == | ||
<!-- | <!-- Describe things which should be discussed regarding the proposal. Specifics that need narrowing down, or contentions parts of the proposal. --> | ||
=== What is the critical path of actions? === | |||
* graphical network install | |||
* post-install booting | |||
* decrypt encrypted filesystems | |||
* graphics | |||
* login | |||
* networking | |||
* get updates | |||
* minimal buildroot | |||
* compose new trees | |||
* compose live | |||
=== What teams provide the extra attention? === | |||
QA/Releng are good suggestions, however these groups will have to make clear how new members can join the groups and what the responsibilities are. | |||
=== When and how to determine packages within the path === | |||
Because deps change, we'll have to regenerate the list of packages at certain intervals. Once per release may or may not be enough. | |||
=== | === Spins === | ||
How can spins define their own critical path and keep track of changes within their path? | |||
== | === Maintainers who do not wish to maintain critical path packages === | ||
Will they be informed early enough to find alternative maintainers? | |||
== Comments? == | == Comments? == | ||
| Line 29: | Line 55: | ||
[[Category:Proposals]] | [[Category:Proposals]] | ||
[[Category:FAD]] | |||
Revision as of 14:31, 10 June 2009
Overview
Define a "Critical Path" set of packages that require special care when updating in rawhide and releases.
Problem Space
Currently documented policies treat every package the same. While this is good for uniformity, in reality certain packages require and have been given extra attention and care when updating and testing. These packages have potential to break the critical path of use of our Fedora distribution.
Proposed Solution
Define a set of actions and their packages/deps to provide those actions that to define the "Critical Path". Packages within the "critical path" have extra requirements on getting tagged for freeze breaks and updates.
Scope
- Maintainers of packages within the Critical Path
- QA/Releng to provide extra attention to update/freeze requests for packages within the critical path
- Bodhi to handle extra requirements
- Tooling to define Critical Path each release
- Documentation
Active Ingredients
Bodhi is the most active ingredient here. It will have to handle blocking the update packages within the critical path until it gets the extra attention from QA/releng
Discussion Points
What is the critical path of actions?
- graphical network install
- post-install booting
- decrypt encrypted filesystems
- graphics
- login
- networking
- get updates
- minimal buildroot
- compose new trees
- compose live
What teams provide the extra attention?
QA/Releng are good suggestions, however these groups will have to make clear how new members can join the groups and what the responsibilities are.
When and how to determine packages within the path
Because deps change, we'll have to regenerate the list of packages at certain intervals. Once per release may or may not be enough.
Spins
How can spins define their own critical path and keep track of changes within their path?
Maintainers who do not wish to maintain critical path packages
Will they be informed early enough to find alternative maintainers?
Comments?
To leave a comment, use the Talk page for this proposal.