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] <[EMAIL PROTECTED]> and a more verbose
> statement about my wish for clear removal procedures in
> <[EMAIL PROTECTED]>
"If you'd like to work out specific rules for either case and propose an
amendment, you can, of course."
Cheers,
aj
signature.asc
Description: Digital signature
