Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi, Stephen Gran wrote:
> I took those two in
> particular to be guidelines, rather than strict quantifiers.
That's not how I was reading that list.
> The
> problems they appear to be trying to address with these points are
> hardware availability and buildd admin time.
If no more working hardware is available sometime in the future, drop the
arch *then*.
If there is no buildd [admin] time available, *add more buildds*
[buildd admins].
> If
> you want to see some points of the proposal changed so that it gives
> your pet arch a chance to be included in stable, then make proposals
> instead of assuming those who disagree are illiterate.
>
There's a difference between being illiterate and missing something.
Please don't assume that I insinuate the former; AFAIK I didn't.
Please also don't assume that I *have* a pet arch.
> So far as I can tell, the governing rule in Debian thus far has always
> been that the people doing the work get to make the decisions about
> their corner of the project.
My recollection is somewhat different, in that in Debian, people seem to
be perfectly within their rights to say "this is my corner of the project,
and the fact that I'm not doing anything about $corner at the moment is
not a problem -- it's still mine, and therefore your offer to help with
$corner is declined".
That problem will not go away by dropping $ARCH.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Reply to: