Re: my thoughts on the Vancouver Prospectus
On Fri, Mar 18, 2005 at 06:44:46PM -0800, Steve Langasek wrote:
> [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.
Which is solved by going with delayed stable release, separate testing
process, and delayed security updates if necessary, so hardly a point.
> - 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.
That said, it only affects said port, and i believe the people in the m68k
community may thrust them more than they thrust us, and rightly so, given how
the plan to drop them is.
> - 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.
But there are intermediate steps possible between full support and the current
let's forget about them and let them fend for theirself proposal you did make.
> 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.
Why didn't you take less drastic solutions in consideration ? Or if you did,
why didn't you speak about them ?
Friendly,
Sven Luther
Reply to: