Hi, On Wednesday 16 April 2008 18:51:36 Loïc Martin wrote: [..] > > > 1. Is it possible to review what are the most frequent packaging errors, > and how much of these can be picked up by a few scripts? > > IMHO, most new contributors would omit debian/copyright, or tend to > indicate the wrong Ubuntu version (i.e. the stable release instead of > the development one, since at first you're not going to know about SRU > policy), leave the Debian one, forget to fill some fields in > debian/control, include binaries, etc... > > Could it be possible to automate most of these checks and others, so > each uploader would get feedback on the first screening errors ( a > process which, at the moment, can take 2+ weeks)? The system could point > to the relevant parts of the documentation (hypertext links or extracts) > for each problem, and provide information on how to receive human > interaction if necessary - irc, mailing list or, better, a packaging > forum since Windows users aren't used to irc and mailing lists). In > short, a kind of lintian for common mortals, but server-side.
hm... that's tough. Well, there is lintian, but not all of lintian output is
always correct for each source package (that's why you can override parts of
it). So the tricky part here is: What to do with the result of a package
checker? (should it reject the package, which would be wrong for some, should
it leave a negative reviewing comment, same problem, or should it just be
informational, which is what we have right now, though not really presented
very nicely).
Others than that, someone would have to write such a checker, in case lintian
doesn't fulfill the needs. Running that on the server - given that it's
particular secure to do so - shouldn't be a problem.
>
> Result : the packager gets immediate input, and reviewers know that
> they're only reviewing pre-screened packages which should already build
> and meet a few basic standards. How costly would it be for the server to
> try and test building each upload - getting the tarball, applying the
> patches, trying to build the package, and even trying to run it?)
Autobuilding: autobuilding is basically handing out a root shell on the box,
so this won't happen.
>
>
> 2. When the new package is uploaded, the uploader's email could be added
> as a bug contact, while all reviewing comments (including the automated
> screening results) are forwarded to its email address, ensuring nobody
> loses touch with their package unless they'd really have no interest in
> it (which I assume isn't the case in the first place).
Well, we have the motu-reviewers mailing list. I'm not sure if I'd like to get
an additional email myself, but this shouldn't be too tough to do in case
other people feel the same way. (I guess the hardest part is finding out
where to send the email, since it involves looking up the signature of the
changes file and finding out the email address of the signature).
Cheers,
Stefan.
signature.asc
Description: This is a digitally signed message part.
-- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
