On Mon, Jul 30, 2007 at 10:36:46AM +0200, Marc 'HE' Brockschmidt wrote: > (i) You have added a policy for everything, but removal from the DM list > is still under-defined. Yes. I haven't seen an example of removing a contributor that's worked well, so I don't have a process *to* define. At present any group of two or more DDs that can come up with a reason is enough to justify a removal. If that turns out insufficient -- people are too shy to suggest DMs get removed when they need to be, eg -- it can be changed; if it turns out to be too easy -- good DMs removed for minor mistakes that they've already uploaded a fix for, eg -- it can also be changed. > This is a crappy idea. Imagine a Sven Luther case in DM - > someone who's technically capable and invests a lot of > time, but leads to regular flamewars. Having them be a DM or not won't stop the flamewars, and unlike being a DD there's no implication that DMs have rights to post to Debian mailing lists. Given the proposed rules, any DD can remove any DM from maintaining any package by doing an NMU (to fix RC bugs the DM introduced, eg). > Now, back to the Sven Luther example: Imagine how > *that* flamewar would look if the procedure to kick him out would > have been hand-crafted just for his case? Absolutely no different to how it actually happened. > (ii) Debian has a QA problem. Sponsorship did nothing to improve it. In > fact, I believe sponsorship to be one of the reasons for it. On that score, I agree. I would further say there are three main aspects to that: - sponsored maintainers are inhibited from fixing bugs they introduce; if their regular sponsor is missing or they don't have a regular sponsor, bugs will be left unfixed until they can find someone else -- in spite of someone being aware of the problem, ready with a fix, and wanting to upload it. - there's no tracking of sponsored maintainers, so it's possible for sponsored-maintainers to shop around for someone to sponsor their packages if they're uploading something someone rejects; "when mummy says no, ask daddy", except multiplied by up to 1000 developers. - it doesn't matter if the maintainer is good, only if the package is, so sponsorship doesn't promote skills that help avoid bugs being introduced so much as remove specific bugs that the sponsor manages to spot The proposal addresses all those things -- it makes it easier for non-DD maintainers to upload fixes, it provides a central point to track non-DD maintainers so that if someone tends to do really good work it can get passed on to other people, or if they make lots of mistakes, we can remove their uploader status in one step, and it promotes advocacy of non-DD maintainers who have demonstrated skills and useful contributions rather than who've just managed to put a good package together. > (1) Someone needs to advocate a maintainer, [...] > (2) As soon as someone is in the DM keyring, a DD can give him > upload rights for virtually every package by adding the DM to > the Uploaders field and adding the DM-Upload-Allowed field. > This concept is completely ignoring the problems that sponsoring > exposed - in fact, it makes these problems worse. The number of > checks done by DDs is reduced to one examination of an initial set > of packages by the DM keyring maintainers [5]. The set of packages That's not true: *someone needs to advocate the maintainer*. For sponsored uploads, that's not necessary. Further that advocacy has to be public, and is thus able to be reviewed, and if that review is sufficiently negative that it gives multiple developers reason to request that DMs removal from the DM keyring, well, game over. > [6] In fact, my original understanding of the whole idea was that a > small set of DDs (like the proposed DM keyring maintainers) would > check every package before a DM would be allowed to upload it on > its own. I thought that to be something very, very positive, as it > would ensure at least one thorough and proper check, instead of the > current tradition of minimal checking done by sponsors. I don't think I've ever seen that interpretation before. I certainly don't remember seeing it. I don't think reviewing packages like that is something I'd like to do, personally. Personally, I'd like to get this started, do nothing more myself than dak work and keyring management, and end up with the dak stuff properly automated, and the keyring stuff handed over to someone else. If there are other people who are willing to do that sort of review -- and it's something that would need to happen for a series of patches or sponsored uploads prior to being listed as Maintainer: I'd think -- then there would be two ways of doing it if the existing proposal passed: - having that group of people available to review and advocate potential DMs as part of the initial application for entry into the keyring - having that group of people review uploads that are accepted into the archive by people newly added to the Maintainer: field, and reporting on cases that would have failed the review, with failures presumably resulting in apologies and fixes, removal from the Maintainer: field by whoever added them, or removal from the DM keyring In either case, if the work the group does really does turn out to improve Debian then passing the checks will result in DMs that are more likely to stay in the keyring (not to mention go on to being a DD) and people will naturally want to pass them, and if the value is as great as you predict it'll become either de facto or explicit policy for all DMs. If it turns out to be too much work for too little benefit, or there just isn't anyone to do it, otoh, it won't get in the way of making what improvements we actually. can. > [7] <87bqf85pjd.fsf@pindar.marcbrockschmidt.de> and a more verbose > statement about my wish for clear removal procedures in > <877ipw5i1m.fsf@pindar.marcbrockschmidt.de> "If you'd like to work out specific rules for either case and propose an amendment, you can, of course." Cheers, aj
Attachment:
signature.asc
Description: Digital signature