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

Re: Ideas about a GR to fix the DAM

On Sat, Nov 17, 2007 at 09:00:43PM +0100, Pierre Habouzit wrote:
>   Though, you skip a tiny little detail: how do you will make this real?
> Not technically, I believe all those things you describe are technically
> trivial. I mean socially. We have the current issue that:

I don't think there's anything to be done until the technical things are
solved. Demonstrating that a DM keyring can be maintained by a team would
be helpful to show that the DD keyring can be maintained by a team, but we
haven't done that yet. I don't think anyone else (outside of Debian) has
either. (As far as convincing James goes, jetring has the further problem
that it's a bunch of perl and shell scripts; and he's a dead-set python
addict these days -- but at least jetring's designed such that there's
nothing stopping us from writing a compatible replacement in python)

>   1. James doesn't feel he is a delegate, because he predates the
>      constitution (it awfully sounds like a ???the rules convenientely
>      only apply to others??? btw).

IMO, there's two sets of rules, one for delegates (DPL can assign/dismiss,
etc), and one for maintainers (miniature god, though tech-ctte and
GR can review/overrule).  For "policy" decisions (who's a DD, what is
acceptable for Debian to distribute, is it okay to flame people, etc)
the delegation rules fit best IMO; for "technical" decisions (adminning
the LDAP database, keeping the upload queues working, keeping the list
archives up, etc), the maintainer rules fit best. That still leaves a
problem when it's not clear whether a role/decision is a policy issue
or a technical one, though, which is why I think it's worth making the
distinction clear and trying to separate roles amongst different people.

That's _my_ opinion though, not necessarily anyone else's. 

In any event, the fact that James hasn't reblocked binary-only uploads
for arm, or unimplemented the DM changes should be evidence enough that
he doesn't think "the rules" don't apply to him.

>   2. James doesn't trust Joerg, and I believe doesn't trust a lot of
>      people to be up to the task, so he will likely reject many of the
>      proposals that will be made to him about this issue.

The real problem is that James actually has good reasons for why a lot
of proposals for fixing things won't actually work well. If he didn't
have a history of sound judgement, it'd be really easy to just ignore
whatever he thought and do something different.

>   3. We had a discussion at Debconf8 with James about NM, and he didn't
>      thought he was doing a bad job, he doesn't _think_ he is a
>      bottleneck.

That's not really the right question, though. Bottlenecks come and goa:
sometimes James has time and interest so things pass through his todo list
quickly, other times they don't; ditto Joerg; ditto AMs; ditto everyone.
The real issue is increasing the bandwidth by a whole bunch of metrics:
max throughput, average throughput, minimum throughput -- and that
applies at every stage. 

You can improve things by:

	- making things more fun and rewarding (so people are more inclined 
	  to dedicate more time)

	- making things easier (so each person can do more things)

	- having more people able to do each thing (eg, more DAMs,
	  or making it easier for multiple AMs or other DDs to help an
	  individual applicant progress)

	- reducing dependencies (so that people's free time doesn't
	  have to come in a specific order -- eg, nm has very strict
	  dependencies: application, advocate, FD, AM, FD, DAM, keyring,
	  DSA, and often further dependencies in the AM stage -- AM
	  introduces, applicant replies, AM asks questions, applicant
	  replies, AM suggests an upload, applicant prepares one,
	  sponsor uploads, appicant notifies AM, AM checks upload...)

(Random analogy to network optimisation: fun == pay for a bigger pipe;
easier == compress your traffic; more people == redundant independent
servers and p2p; reducing dependencies == having a queue of transactions
to maximise your b/w, so latency and dropped packets don't hurt so much)

>      And at the time he was kind of right, [...], so he was
>      rejecting the delays on the ???over-administrative-thing??? NM has
>      become since he created the concept (at the time it was a
>      James-phone-call-at-home, no surprise the current form is quite a
>      shock to him), [...]

Uh, where'd that myth come from?

Before the huge bureacracy nm is today, it was "send your key
to new-maintainer, and Joey or James will call you to check you're
real and sane, and create an account". That changed when Joey closed
new-maintainer in July 1999 and the development of the new process only
really began with James officially stepping down from new-maintainer in
October 1999. Wichert proposed more or less the process we have now in
October which had a bunch of discussion, and eventually got announced
by Dwarf in February 2000 with Joey and James resuming their roles in
n-m under the new title of DAM. You can follow all this on the -private
archives on master.

James was directly involved in getting the current form to happen;
the need for change was a shock to the rest of us, not James or Joey.

Of course, at least according the LWN's 2000 timeline [0], by December
2000 "The Debian new maintainer process draws complaints for its length
and slowness. Not everybody agrees that it is a problem, however; some
do not want it to be easy to become a Debian maintainer."

Since that time it's gotten quite a bit more procedural still (with
question lists, and rules about contributions before applying, and not
passing through without already being an active maintainer, and aiui on
average a much more thorough review of applicants).

>   4. At least the 3 last DPL, plus now sam tried to address that, and
>      well, I'm not sure it's even moving in any direction right now.

Well, fwiw, I deliberately tried not to address it, under the hope that
all the attention and complaints were causing undue stress which was
preventing any useful changes. It still seems a reasonable theory, but
didn't seem to do any good in practice. *shrug*

> So the real question is, how do we overcome those issues, those
> _social_ issues ? jetring isn't going to fix that. Meanwhile we are
> driving excellent contributors crazy, and it kills me.

I think if there were an easy solution, we'd have found and implemented it
already. Until we figure out how to make a hard solution work, implement
it and demonstrate the solution works in practice, I think we should
find as many ways to work around the problems as we can. Obviously, YMMV.

In any event, getting angry about it has certainly been tried lots of
times before, I don't think it's achieved much improvement to date.


[0] http://lwn.net/2000/features/Timeline/?month=dec

Attachment: signature.asc
Description: Digital signature

Reply to: