NEW Packages process

Loïc Martin loic.martin3 at
Wed Apr 16 17:51:36 BST 2008

I'm no MOTU and just speak from a newbie uploader's perspective.

Daniel Holbach wrote :
> Hash: SHA1
> Stefan Potyra schrieb:
>> One argument against it raised in the past is, that this might lead to fewer 
>> people reviewing a package (or giving an ACK for a package), as they might be 
>> unsure about it.
> Maybe the right fix for this the situation is to establish an easy way to
>  - solicit feedback about a packaging situation one is unsure about
>  - document the "best way to solve problem X" either in
> or
> I can see a number of additional benefits in this solution.

I'm no MOTU or REVU expert, so I might be completely OT (if so, just 
disregard my comment) but from what I've understood from scarce contacts 
with uploading a new package and uploading one packaging patch in 
Launchpad, there's a few questions/suggestions :

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.

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?) The 
system could even replace all Debian versions or wrong Ubuntu versions 
in debian/control by the development one, and see if it still builds/run.

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

I can imagine lots of people disappear after having uploaded a package 
because they just stopped checking everyday for feedback after 2 weeks 
or so. Having an email appear in your letterbox even when you'd long 
forgotten you ever uploaded a package could solve that problem (who in 
their right mind would force themselves spending 10 min a day on that 
when there's no indication you'll ever receive an answer before upstream 
releases a new version, forcing you to restart the counters - 2+ weeks 
wait before any new review).
After 2 weeks, either you imagine nobody's going to review your package, 
  or - at best - you imagine there's always going to be a 2+ weeks delay 
at each step of the process.

Having automated screening/answering could save a lot of unproductive 
time from MOTU. It would be a guaranty that they'll never be spending 
time on a package whose uploader might disappear, since they'd known the 
uploader was willing to fix the first packaging errors and has already 
learnt a bit in the process. First-time uploaders don't have a break 
between the upload and the fixes, so their interest is keen. A 2 weeks 
wait also does a lot of harm in any learning process (ask any teacher) 
since you'll have forgotten most of what you already had to learn in 
order to build your first package - that means losing a few days again 
just to get to the level you were when you uploaded the package in the 
first place, then learning new information to fix your errors.

Having an email process also ensures no uploaders forget their uploads, 
while Help - and explanations on how to get it - is available to the 

That's a long email for what is just my two cents.


More information about the Ubuntu-motu mailing list