Guidelines for reviewing new packages.

[Scott Kitterman]

On Mon, 12 Nov 2007 20:30:16 +0100 Emilio Pozuelo Monfort 
<pochu at ubuntu.com> wrote:
>Emmet Hikory wrote:
>> Reviewers and Packagers,
>> 
>>     At the recent MOTU Meeting, a set of guidelines for new package
>> review was reviewed.  This list is meant to supplement reviewers base
>> opinions when reviewing packages, and provide for a relatively stable
>> set of criteria when packagers are deciding if their packages should
>> be uploaded to REVU.  Please keep these guidelines in mind when either
>> packaging new software or reviewing candidates for upload.  The
>> guidelines are broken into three separated goal-oriented sections, as
>> follows:
>> 
>> Packaging review
>>     1.  Package must meet Ubuntu versioning & Maintainer requirements
>>     2.  Package must match current Ubuntu (and Debian) packaging policies
>>     3.  Package should be linda & lintian clean
>>     4.  Contents of debian/ should be sane
>
>While I find there guidelines really appropriate, I would like to propose
>another point:
>
>     4b.  Contents of diff.gz should be in debian/. i.e. no inline 
patching.
>
>I say this because I looked yesterday at wxwidgets2.6 merge. And it was 
really
>difficult for me, since a) patches were applied inline in the source and 
b) it
>was a native package, so I didn't have a diff.gz to look for our patches. 
So I
>would propose that inline patching is only allowed for SRUs and Security
>updates. Of course if the package isn't native it will have the changes in 
the
>diff.gz, but anyway that's not ideal.
>
>What do you guys think about it?

I'd suggest that we not be to pedantic about it.  There are valid reasons 
not to use patch systems.  Additionally, adding a patch system to a 
traditional dh rules based package can be a dauntingly non-trivial exercise 
for a new contributor.

As an example of a case where I think a patch system would have been 
inapprpriate, I uploaded a one line change to courier shortly before gutsy 
released.  I did it inline and not as a patch.  I did it this way for the 
following reasons:

1.  It was close to release and I felt that monkeying with debian/rules to 
add a patch represented a risk that there wouldn't be a lot of time to 
retire.

2.  The change was already in the next upstream release and in Debian, so I 
knew it wouldn't have to be maintained.

3.  It was only a single line change.

Debian has a hard and fast rule about patch systems (although I still 
sometimes see inline changes from Debian).  Ubuntu has traditionally been 
more flexible.  I would like to see proper patching encouraged, but not 
required.  This policy flexibility has, I think, generally served Ubuntu 
well.

Scott K