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

Re: Bits from the ftpmasters

On Sun, Feb 20, 2005 at 09:06:36PM +0100, Goswin von Brederlow wrote:
> Joel Aelwyn <fenton@debian.org> writes:
> > Now, if the reason is because everyone involved in ftp-master has more
> > crucial tasks to do with getting Sarge out the door, that would be one
> > thing; the answer would be "Wait" if we're expecting that to last a couple
> > of weeks at most, or "train an additional person" if we expect it to
> > persist (yes, I *know* training someone "costs", but it also pays off
> > fairly rapidly, thus the patience-if-it's-short).
> The NEW queue hasn't been the most expedient for some time now which
> would indicate this is a long term problem. Unless the reason for the
> delay is too many people fighting over the decision then more manpower
> can't hurt, right.

With the caveat that it needs to be manpower usefully applied, I would
agree. What "useful" applications are available is one of the questions.

> Let me repeat two ideas I mentioned before:

I also missed these, previously. Which is a pity. They both seem like they
could be quite useful, if the problem is "the NEW queue is a pain in the
arse to deal with and not very rewarding".

> - uploads to NEW need an advocate in addition to the normal signature
>   The advocates job would be to test the package, check for packaging
>   mistakes, gross bugs, build failures, license, bad name choice when
>   splitting a package. That sort of thing.
>   This would be helpfull in filtering out more bad uploads to NEW. Is
>   that a frequent thing? How much time is wasted on trivial
>   rejections currently?

Hmmm. Seems like it could work, but might still have the issue that finding
two maintainers who think something is good is not vastly more difficult
than finding one; also, many packages are already co-maintained, would you
allow co-maints to both sign it? I believe it *is* possible to get multiple
signatures with GnuPG (the same way you can encrypt something to multiple
keys), but I'd have to go dig through the docs to figure out how to do it.

> - a NEW team
>   The new team would be an appointed group (not just random DD as for
>   the advocate) of DDs that do all the checking and testing of NEW
>   packages and recommend to ftp-master to accept a package in the
>   end. This would mean the ftp-master would loose some of their duties
>   and only be the implementing tool (with a veto right?).
>   Having a NM team has worked great to NM. Maybe that success could be
>   repeated.

This seems like it might be a little easier. Among other things,
processing the NEW queue has very different requirements, in many ways,
from the rest of the ftpmaster jobs described in the document.

1) Requires a high degree of interaction with other DDs, including things
that can frequently go sour, like rejection notices. Often requires
patience and tact beyond what may be reasonable to expect of all DDs, or
even all ftpmasters.

2) Requires investingating new packages for things like licensing (thus,
needing to follow debian-legal to some degree), requires going over the
basics of the package structuring (at least, this seems to often be done;
I've had first-pass uploads rejected for being "split into too many small
pieces", even if we don't expect them to catch bugs), etc. Often tedious.

3) Doesn't (as far as I can see offhand) require access to sensitive
accounts, key signatures, or software. Thus, someone who processes NEW as
a "generate recommendations for ftpmaster" can do the job without needing
much, if any, in the way of privileged access (possibly some issues with
crypto, but those should be easily resolveable).

I suspect that if this was a good answer, it would require some startup
effort (pick one or two folks to learn the basics, get them up to speed,
maybe sort out semi-standard forms and checklists of "things which need
to be answered", and possibly work out some sort of coordination system,
though that might be as simply as "yell down the hall" emails), after
which the NEW processors could do most of the training for additional NEW

Certainly either of them seems like a worthwhile thing to try, if the
problem is "need more manpower"; the main question is whether an advocate
system is really enough to cut down on the difficulty of the task (I have
my doubts, but it might cut down on the number of bad/hard-to-check things
getting into the queue in the first place... or might not), or whether
having more non-privileged manpower to process the queue down to a simpler
"Looks good", "Looks questionable, here's why" or "Needs to be rejected,
here's why" (or give them the power to flat-reject something to them, even)
is more useful.

Not that I expect, given how this and past conversations have gone, that
they'd particularly want to deal with me, but if a NEW processing group is
considered worthwhile, consider me volunteered to put in the time. Maybe
the work is suitable revenge for having to read or delete so many of my
Joel Aelwyn <fenton@debian.org>                                       ,''`.
                                                                     : :' :
                                                                     `. `'

Attachment: signature.asc
Description: Digital signature

Reply to: