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. Cheers, aj [0] http://lwn.net/2000/features/Timeline/?month=dec
Attachment:
signature.asc
Description: Digital signature