Critical Path Packages Proposal: Difference between revisions

Latest revision as of 14:46, 7 July 2010

For information on the implementation and the current state of critical path, see Critical path packages.

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. During freeze/slushy periods a critical path package will require the signoff of someone from releng or qa before the package is allowed in. Additionally, updates being pushed directly to stable must be signed off by someone from releng or QA.

Scope

Maintainers of packages within the Critical Path
QA/Releng to provide extra attention to update/freeze requests for packages within the critical path - must sign off.
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.

The current proposal is to add a package group to comps which lists the packages required to handle the critical use cases discussed above. Listing those packages and all their dependencies would yield a full list of Critical Path Packages.

Will Woods and Seth Vidal have come up with a tool and a list to output packages currently in the critical path.

The lists of packages have been added into rawhide/f12's comps.xml. There are three groups

@core

@critical-path-base

@critical-path-gnome

more can be added.

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

If a package is added to the critical path list as a result of normal package dependency the package maintainer will be notified through direct email and the extra processes they have to go through. If they do not wish to maintain the packages with these extra processes then they have to orphan the package. A new maintainer will have to be found.

Comments?

To leave a comment, use the Talk page for this proposal.

Owner

User:skvidal

@@ Line 1: / Line 1: @@
+{{for|information on the implementation and the current state of critical path|Critical path packages}}
 <!-- This is the FESCo proposal template.  It is not necessary that you use this template but it is encouraged that you do.  It will help FESCo focus on the issue being addressed and the parts that need discussion, as well as identify the scope of the proposal. You may remove all these comment sections from your proposal. -->
 == Overview ==
+Define a "Critical Path" set of packages that require special care when updating in rawhide and releases.
 === Problem Space ===
 <!-- 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 ===
 <!-- 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. During freeze/slushy periods a critical path package will require the signoff of someone from releng or qa before the package is allowed in. Additionally, updates being pushed directly to stable must be signed off by someone from releng or QA.
 === Scope ===
 <!-- 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 - must sign off.
+* Bodhi to handle extra requirements
+* Tooling to define Critical Path each release
+* Documentation
 === Active Ingredients ===
 <!-- 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.
+The current proposal is to add a package group to comps which lists the packages required to handle the critical use cases discussed above. Listing those packages and all their dependencies would yield a full list of Critical Path Packages.
+Will Woods and Seth Vidal have come up with a tool and a list to output packages currently in the critical path.
+The lists of packages have been added into rawhide/f12's comps.xml. There are three groups
+@core
-==== Component 1 ====
+@critical-path-base
-<!-- The first of a list of prerequisites, and what exactly needs to be done with it -->
-==== Component 2 ====
+@critical-path-gnome
-<!-- The second of a list of prerequisites, and what exactly needs to be done with it. Add more subsections as needed for additional components. -->
-== Discussion Points ==
+more can be added.
-<!-- Describe things which should be discussed regarding the proposal.  Specifics that need narrowing down, or contentions parts of the proposal. -->
+=== 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 ===
+If a package is added to the critical path list as a result of normal package dependency the package maintainer will be notified through direct email and the extra processes they have to go through. If they do not wish to maintain the packages with these extra processes then they have to orphan the package. A new maintainer will have to be found.
 == Comments? ==
 To leave a comment, use the Talk page for this proposal.
+== Owner ==
+[[User:skvidal]]
 [[Category:Proposals]]
+[[Category:FAD]]

Search