NEW Packages process

Stefan Potyra stefan.potyra at
Wed Apr 16 18:40:48 BST 2008


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : 

More information about the Ubuntu-motu mailing list