Differences between revisions 2 and 3
Revision 2 as of 2005-03-15 06:17:09
Size: 1915
Editor: anonymous
Comment:
Revision 3 as of 2005-03-15 06:28:08
Size: 2123
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:

 * How will it be determined if a newly proposed architecture has a large enough user base to consist of 10% of all mirror downloads before that new architecture is actually added to the mirrors?
Line 13: Line 15:
 * The guidelines for eligibility as a released architectured, and for inclusion in SCC, could be initially met, but later fail. For example, an architecture could fall below the 98% up-to-date mark. Does this spell automatic expulsion from the slate of releasable architectures? Similarly, for how long are the petititions for inclusion in SCC (5 developers and 50 users) assumed to remain valid?  * The guidelines for eligibility as a released or mirrored architecture, and for inclusion in SCC, could be initially met, but later fail. For example, an architecture could fall below the 98% up-to-date mark. Does this spell automatic expulsion from the slate of releasable architectures? Similarly, for how long are the petititions for inclusion in SCC (5 developers and 50 users) assumed to remain valid?

The following is a list of questions (and, hopefully, answers) regarding the "Vancouver Prospectus", the proposal for Debian release management intended to take effect for etch (sarge+1), and assembled by the Debian release managers and archive administrators at a meeting in Vancouver, Canada in early March 2005.

  • Why is the permitted number of buildds for an architecture restricted to 2 or 3?
  • How is it that none of the four architectures to be released with etch (i386, powerpc, ia64, amd64) have the bare minimum 2 buildds, and yet all are still considered releasable? (N+1 buildds are required; presumably N is 1 rather than 0, since most developers will not upload a binary package for each of the four architectures every time they release a new source package.)
  • How will it be determined if a newly proposed architecture has a large enough user base to consist of 10% of all mirror downloads before that new architecture is actually added to the mirrors?
  • Three bodies (Security, System Administration, Release) are given independent veto power over the inclusion of an architecture.
  • Does the entire team have to exercise this veto for it to be effective, or can one member of any team exercise this power effectively?
  • Is the availability of an able and willing Debian Developer to join one of these teams for the express purpose of caring for a given architecture expected to mitigate concerns that would otherwise lead to a veto?
  • How often can/should these bodies be petitioned for a reconsideration of their veto in light of underlying changes in circumstance?
  • How will the exercise of a veto be communicated to the Project?
  • The guidelines for eligibility as a released or mirrored architecture, and for inclusion in SCC, could be initially met, but later fail. For example, an architecture could fall below the 98% up-to-date mark. Does this spell automatic expulsion from the slate of releasable architectures? Similarly, for how long are the petititions for inclusion in SCC (5 developers and 50 users) assumed to remain valid?