[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: my thoughts on the Vancouver Prospectus

[cc:ed back to -devel, since these are technical questions being raised and

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

>   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

Reply to: