NEW Packages process

Cesare Tirabassi norsetto at
Wed Apr 16 13:02:29 BST 2008

On Wednesday 16 April 2008 13:28:20 Daniel Holbach wrote:

> How do we justify "this needs two reviewers - we don't trust one of them
> to do it right"? 

> It all boils down to the question: "Why don't we trust one MOTU to get
> it right?"

Its not a question of trust, its a question that 4 eyes see better than 2. I 
know I don't rely on my packaging skills alone, no matter how much I work I 
will always miss something.

> Is the quality of packaging our main concern?


> Please decide on your own how common a situation like this is on REVU:
>  - comment by a MOTU: "Could you add a watch file? Please move Homepage
> URL to its own Homepage field.", no ACK
>  - two weeks of inactivity
>  - upload archived
>  - some days later: new upload fixing the issues
>  - ...
>  - maybe an ACK, maybe not

Very good example, and a showcase of why devs are not very keen in reviewing.
First, the contributor missed even the more fundamentals of a package (other 
examples are native packages which are not, wrong standards, wrong 
distribution, etc.), so the reviewer instead of spending a whole morning 
reviewing the package just points out the more obvious (I would and never 
have done this by the way, this is a side product of having one reviewer 
trying to "triage" a long queue). Even then the contributor waits two weeks 
to make a fix which just takes 5 minutes at the most. Is he really interested 
in packaging? If I were the reviewer I don't think I will want to spend my 
time in reviewing things that will eventually just get thrown out of the 

By the way, how will lowering the required acks to one solve the above 

> I'm convinced that fixes (fixing the Homepage field, bumping up the
> Standards-Version, etc) above are written quickly once the package is in
> the archive and should not block an upload.

Should I ack a package that I know doesn't meet the required standards? I, for 
one, will not want to see Universe become another automatix or deb-o-matic.
The right approach here (and this is quite often used) is to say: this is 
wrong but I'm not blocking for this so that the contributor knows about it 
(and a good contributor will upload a fix shortly after).

> We are a distributed team  which maintains packages in the team and
> round-trips because of such things merely add frustration.

Having gone very recently through this, yes, it adds frustration and is as 
much a fault of the contributor as of the reviewer. By lowering the bar we 
are not doing anyone a favour, just lowering the quality of the archive.


More information about the Ubuntu-motu mailing list