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:
pgpjJHnKcrQ0p.pgp
Description: PGP signature