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

Re: my thoughts on the Vancouver Prospectus

> > * 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

> - 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.


Peter (p2).

Attachment: signature.asc
Description: Digital signature

Reply to: