[cc:ed back to -devel, since these are technical questions being raised and answered] On Mon, Mar 14, 2005 at 10:48:10PM -0500, Branden Robinson wrote: > The next stage in the process is to actually sell the proposed changes for > etch to the developers at large[2]. There are several points which can and > should be discussed; I myself am not certain what the motivations for some > criteria are, and it would be good to have those documented so that we can > tell if an when they no longer apply. > Let me offer some examples: > * Why is the permitted number of buildds for an architecture restricted to > 2 or 3? - Architectures which need more than 2 buildds to keep up with package uploads on an ongoing basis are very slow indeed; while slower, low-powered chips are indeed useful in certain applications, they are a) unlikely to be able to usefully run much of the software we currently expect our ports to build, and b) definitely too slow in terms of single-package build times to avoid inevitably delaying high-priority package fixes for RC bugs. - If an architecture requires more than 3 buildds to be on-line to keep up with packages, we are accordingly spreading thin our trust network for binary packages. I'm sure I'll get flamed for even mentioning it, but one concrete example of this is that the m68k port, today, is partially dependent on build daemons maintained by individuals who have chosen not to go through Debian's New Maintainer process. Whether or not these particular individuals should be trusted, the truth is that when you have to have 10 buildds running to keep up with unstable, it's very difficult to get a big-picture view of the security of your binary uploads. Security is only as strong as the weakest link. - While neither of the above concerns is overriding on its own (the ftpmasters have obviously allowed these ports to persist on ftp-master.debian.org, and they will be released with sarge), there is a general feeling that twelve architectures is too many to try to keep in sync for a release without resulting in severe schedule slippage. Pre-sarge, I don't think it's possible to quantify "slippage that's preventible by having more active porter teams" vs. "slippage that's due to unavoidable overhead"; but if we do need to reduce our count of release archs, and I believe we do, then all other things being equal, we should take issues like the above into consideration. > * Three bodies (Security, System Administration, Release) are given > independent veto power over the inclusion of an architecture. > A) 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? It's expected that each team would exercise that veto as a *team*, by reaching a consensus internally. > B) 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? Without knowing beforehand what the reason for the veto would be (and if we knew, we would list them explicitly as requirements), this isn't possible to answer. > C) How often can/should these bodies be petitioned for a reconsideration > of their veto in light of underlying changes in circumstance? In general, I think we would want to see some evidence that the porter team is able to address the objections over the long term, so probably showing that the concerns have been resolved for a month prior to requesting a review would be reasonable. > D) How will the exercise of a veto be communicated to the Project? An announcement mail with Subject: Vancouvered: $arch, of course. > * The guidelines for eligibility as a released 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 petitions for inclusion in SCC (5 > developers and 50 users) assumed to remain valid? I could only imagine enforcing either of these rules against a previously RC arch when it starts adding to the release team's workload by falling behind. > I think it would be quite worthwhile for a FAQ to be maintained on the > Debian Wiki, so that answers to these and other questions can be > collected. As a matter of fact, I just started one[3]. Feel free to incorporate the above answers into that page; as noted before, I don't think a wiki is a very effective tool for ongoing discussions. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature