| Peter 'p2' De Schrijver 2005-03-19, 8:51 pm |
| > > * Why is the permitted number of buildds for an architecture restrictedto
>
> - 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
You're sprouting non-sense here. The vast majority of the debian
packages is useful on slower architectures.
> 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.
>
We now rely on about 1000 developers which can upload binary packages
for any arch and they do not get rebuild by the buildd's. thanks for
playing.
> - 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.
>
Would you please stop generalizing your opinions ? There is an idea in
some people's mind that 12 architectures is too much. If you look at the
number of reactions on this list, you will notice that a lot of people
do not agree with you on this point. So stop inventing bogus arguments
to justify your point.
>
> It's expected that each team would exercise that veto as a *team*, by
> reaching a consensus internally.
>
This is obviously unacceptable. Why would a small number of people be
allowed to veto inclusion of other people's work ?
>
> 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 possibleto
> answer.
>
So drop this bullshit veto thing. There is no reason to have this.
Cheers,
Peter (p2).
|