> > * 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 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. > > * 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. > This is obviously unacceptable. Why would a small number of people be allowed to veto inclusion of other people's work ? > > 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. > So drop this bullshit veto thing. There is no reason to have this. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature