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

Re: Skills check for sponsored packages



On Tue, Aug 20, 2002 at 10:32:21AM +0100, Andrew Stribblehill wrote:
> I'm processing my first applicant and would appreciate some advice
> regarding the skills check.
> 
> My applicant wants to package applications for Debian and has adopted
> two of them, being sponsored by their previous developer.
> 
> Now, I'm not saying there's necessarily anything wrong with these
> packages this time (but there may be).
> 
> Should I apply the same standards of rigour to these packages that I
> do for my own sponsees' packages, namely, perfection ;)? It doesn't
> seem like my place to step on sponsors' toes.

Sponsors suck. I mean, really suck. Lots of stuff gets sponsored that
was completely broken; all too many sponsors do not check packages
thoroughly before uploading them.

I go way above and beyond the demands I make of my own packages. I
attempt to find at least 30 or 40 lines worth of problems to point out
to applicants (occasionally I suggest solutions; I rarely indicate how
important any of these problems are), and if I can't find at least
that much, I'd want them to package something harder ;)

A few places I like to look: read the entire build logs (nobody does
this, so there's usually something in there that's wrong), interrupt a
build at some random point and run debian/rules binary again, read the
diff, build it on some weird architecture, run "find | xargs file" in
debian/ after building, plus anything else you can think of.

Don't be afraid to pick up on things which are not their fault; a bug
in a debian package is a bug in the distribution. If they have to go
and get upstream or the maintainer of some other package to fix it,
that's their problem (and you can observe how they deal with it).

> Alternatively, do I just work on the principle that if it's already
> in Debian and the mistakes were probably made by the previous
> developers, I should just rubber-stamp it?

No, if they're maintaining it, they're responsible for it.

> Maybe there's a solution I'm overlooking but neither of my
> alternatives look reasonable.

Don't try and be nice to applicants. Make them *work* for it. It's not
very polite to invent things for them to do unless you have to, but
that doesn't mean you shouldn't do it when it's appropriate. If they
don't have a few hours to spend demonstrating their competance, then
they probably wouldn't be a very good maintainer either.

[Maybe we should call them "supplicants" instead of "applicants"]

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'                          | Imperial College,
   `-             -><-          | London, UK

Attachment: pgpMdZlZYuywK.pgp
Description: PGP signature


Reply to: