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

Re: vancouver revisited

On Sun, Aug 21, 2005 at 10:16:53PM +0200, Peter 'p2' De Schrijver wrote:
> > - must be freely usable (without NDA)
> > - must be able to run a buildd 24/7 without crashing
> > - must have an actual, working buildd
> > - must include basic UNIX functionality
> Whatever that may mean

That we don't want to host a port that isn't even remotely useful (yet),
and won't be able to build more than half of the archive (or so). Which
is reasonable.

It fits in with the three other requirements just above this one. I
think it's deliberately vague because you can't predict all sorts of
breakages a port can have.

> > - must have a working, tested installer
> Trivial. debootstrap does that. 

Debootstrap is not an installer, in very much the same way that tar
isn't, either.

> > - security team, DSA, and release team must not veto inclusion
> Arbitrary veto power. This requirement is unacceptable for me. Noone
> should be allowed to just ignore other peoples work within the project.

This is one argument I do have sympathy for. In fact, I went to that
meeting with the exact same thought.

The thing is, however, that you're dealing with a madman scenario:
you're afraid that one day, a member of one of the above teams will go
crazy and declare that they don't like this person that works on a port,
or just that port entirely. Or, less extreme, you're afraid that a
member of the above teams will make a judgement error and veto a port
for bogus reasons.

The problem with such an argument is that the reverse is also valid: if
members of those teams can go crazy and drop a port even if it's not
necessary, then other people can also go crazy and refuse dropping a
port, even if it's far more than necessary. In fact, that may be more
likely, since some port maintainers (including myself) are quite fanatic
about their work, and some emotional attachment is not unlikely.
Additionally, the above teams consist of people that have to work with
all our architectures -- if there are problems with a particular port,
then apart from the port's maintainers, they are the ones who'll suffer
the most from it.

That's why we introduced the rule that if one of the teams decides to
use their veto power, they /have/ to explain themselves. If someone then
posts something like "I've had a fight with <foo> the other night, so
I'm going to make him feel sorry for it and drop his port", I suspect
requests will go to the DPL to please replace this person. Or if someone
posts a rationale to drop a port consisting of arguments each of which
are completely and utterly false, that a discussion will follow,
pointing this out, and (ultimately, if the team isn't convinced) a GR to
overrule the decision.

Considering how nobody said that a port's exclusion has to be definite,
I think that is a good compromise.

The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Reply to: