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

Re: Debian needs more buildds. It has offers. They aren't being accepted.



Will Newton <will@misconception.org.uk> writes:

> On Thursday 19 Feb 2004 10:30 pm, Henning Makholm wrote:
> 
> > Letting people into the project and giving them upload rights, votes,
> > et cetera, is a fairly serious matter. I, as a user, would not as
> > happily use Debian if this was done solely on the basis of one
> > individual's judgement. No matter whether that individual is
> > trustworthy in general, he is human and may make mistakes.
> 
> I would agree with that. On the other hand it is worth thinking about the 
> question of whether Debian gets the accept/reject balance right.
> 
> > Does it follow by logical necessity that the third person has to be
> > the DAM? There has to be someone in that position, someone with the
> > guts to sometimes say no where the AM has said yes. And it is
> > desirable that, if possible, it is the same person each time, for
> > consistency in the processs. So there we have the DAM's job
> > description.
> 
> I disagree. I don't think it is desirable that it be one person and they be 
> "consistent". I belive that will risks a monoculture of developers. If, as 
> seems to be have been suggested, the DAM has a problem with impatient people, 
> then we get no impatient people in Debian, regardless of ability. Just 
> because you happen to have the "personality flaw de jour" I don't believe you 
> should be excluded from Debian.
> 
> I would prefer:
> 
> 1. A committee of maybe 3-5 people (that rotates members etc.)

There is the nm-committee, consisting of active AMs that had an NM
turn DD in the last 6 month. That was the rule, right?

.oO( Hmm, there is a scray though. The DAM just has to delay making
some people DDs for some time to get AMs of the team or fasttrack NMs
to get people on the team. Talk about power. :)

> 2. A set of guidelines that include, but do not limit, why a NM may be 
> rejected.
> 3. A public mailing list where all deliberations are archived (or even a 
> debian-private alike list if that is too much).
> 4. If the a committee member (or DAM) has a personal problem with a NM, they 
> should declare a conflict of interest and let some vice-DAM or vice committee 
> member take their place in that case.

That sounds intresting. Should the NM be able to reject the DAM and
choose to be ruled by the vice-DAM too?

How about jury duty? DDs get chosen randomly and can reject being
called to arms, aeh to the DAM committe, twice in a row at most or
something. Just a thought.
 
> It is my belief that that would be fairer than the current system.
> 
> > It does not necessarily follow that the DAM hat needs to be worn
> > together with the exact complement of hats that it is currently
> > sharing a head with, but it is esay to see sound practical reasons for
> > it to at least go together with keyring maintainer and machine
> > administrator hats. In any case, any problems attributable to hat
> 
> I don't think such minor conveniences should ever come into the equation. This 
> question of fairness and transparency is more important than it being 
> slightly quicker to get the key added. If it takes an email and someone else 
> to add the key, so what?
> 
> > concentration are better solved by rearranging hats than by changing
> > the NM process.  (There seems to be a rather screaming lack of
> > consensus about *whether* there is currently any problem worth solving
> > in that way; I do not have sufficient first-hand experience to form an
> > opinion about that question).
> 
> I think the monthly flamewar should be a hint. Even if you personally do not 
> believe there is a problem with the NM process:
> 
>  - Do you believe the regular flamewars are a heinous waste of time and need 
> to stop?
>  - Do you believe it is inevitable that these flamewars will occur?
> 
> I would answer Yes and No. I think we can take steps to minimize the amount of 
> NM process flamage.

MfG
        Goswin



Reply to: