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

Re: The Debian Maintainers GR

Anthony Towns <aj@azure.humbug.org.au> writes:
> After that meeting [0], I'd assumed it was in Christoph and Marc's capable
> hands,

... without ever *asking* if that would be true. I assumed this idea to
be dead because last year's discussion on -newmaint showed that most DDs
were against that proposal.

> Some of them have had some progress including a bunch of accounts created
> during the DPL election, but, some didn't, such as Peter Samuelson's DAM
> processing, which I'd explicitly referred to as an example that should
> have been trivial for the DAMs to process, as any problems should have
> been resolved at AM stage since it was AMed by a FrontDesk member. Peter's
> still in the DAM queue at the time of writing.

As the background for that is private, it would have been nice to keep
it out of this discussion. Anyway, the reason why this problem ended up
in the DAMs hands is because *only* the DAMs were mailed with some
doubts, not the AM. And that only after the AM report was done...

Anyway, I'm really not going to tear apart the little bubble in which
you have placed yourself - I simply don't see how this would help

Now to the actual matter at hand. I had this discussion in IRC yesterday
and it seems that I should explain my opinion about the GR a second
time: [1]

 (i) You have added a policy for everything, but removal from the DM list
     is still under-defined. 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. There is no question that
     we would need to have some procedure to decide what should happen
     in such cases. 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?
     So basically, I won't accept your proposal as remotely sane until
     the initial policy includes some guidelines on removals from the DM

(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. Let's
     explain this a bit:
     Sponsorship is one of the main factors that lead to the explosion
     of the number of packages in the archive. The growth in the number
     of packages is, in fact, much bigger than the growth in the number
     of users. This means that the number of users per package has
     fallen [2], directly translating to the fact that packages receive
     less testing before they are released. This is equivalent to bugs
     and packaging mistakes staying unnoticed for a longer time.
     This problem is almost exclusive to packages that are priority:
     optional|extra, ie packages likely to be maintained by newcomers to

     On the other hand, sponsorship is (besides the few cases were
     people only want to maintain a few packages and not invest more
     time in Debian) used as an education system. It's training people
     on the job, allowing them to understand policies and procedures
     when bugs are reported or their sponsor notices a problem while

     The shrinking user:pkg ratio has already shown it's effect:
     Packages of seldomly used, specialized software are often of low
     quality, ignore licensing problems and aren't integrated into the
     rest of the Debian system as tight as they could be. The
     ever-growing number of RC bugs in sid is a sign for that, a better
     sign is the number of unfixed important bugs [3] and there is
     always the simple test of taking 20 random packages from the
     archive and checking them for obvious packaging problems [4].

     I'm also believing that sponsoring is not as good as it should be -
     people often sponsor software without doing the thorough checks
     that *should* be done.

     Now on to the actual matter: The proposed Debian Maintainers
     concept is splitted into two parts:
       (1) Someone needs to advocate a maintainer, some people need to
           decide if that maintainer should get added to the keyring and
           thus get upload permissions for all packages that carry him
           as Maintainer/Uploaders and have the DM-Upload-Allowed field
           set. Without spelling out how the approval by the DM
           keyring maintainers should happen, I guess most people are
           thinking about checking packages, looking at past work, bug
           handling, ...
       (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 can be uploaded by the DM is something completely different -
     those are "only" checked by a random Debian Developer. Together
     with the low user:pkg ratio, my distrust in the abilities of the
     average and our experiences with sponsored packages, I believe that
     your DM proposal will be a future source of QA problem if it is
     implemented. [6]

Before ending this mail, I would like to point out how frustrated I am
that my concerns have been ignored until now (and probably will be
ignored in the future). I have (once!) explained my position here on
-vote [7]and got only a few answers, none of them actually refuting my
arguments. The current policy on Debian lists seems to be that you are
ignored unless you repeat your opinion as reply to every single mail in
a thread. I'm too busy and simply don't care enough about Debian at the
moment to present my opinion in that manner.

Thanks for listening,

[1]  BTW, I would like to thank the #debian.de people (including buxy,
     who seems to try to get into the s3kr1t german cabal) to help me
     understand which part of my argumentation isn't obvious.

[2]  Yeah, I know that I ignore the fact that the number of packages per
     user isn't stable but has grown itself, but I believe it to be
     unimportant for this case.

[3]  RC bugs get listed and people interested only in the release and
     not in the package itself fix those bugs, while issues of lower
     priority stay unfixed

[4]  My last results for that were that 3/4 of the examined packages
     were - in my eyes - too bad to be included in the archive.

[5]  The current list for the keyring maints at least ensures that no
     sloppy sponsoring is getting through...

[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.

[7]  <87bqf85pjd.fsf@pindar.marcbrockschmidt.de> and a more verbose
     statement about my wish for clear removal procedures in

Attachment: pgpojCMA3UviH.pgp
Description: PGP signature

Reply to: