Guidelines for reviewing new packages.
ubuntu at kitterman.com
Mon Nov 12 22:34:44 GMT 2007
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
>> 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
> 4b. Contents of diff.gz should be in debian/. i.e. no inline
>I say this because I looked yesterday at wxwidgets2.6 merge. And it was
>difficult for me, since a) patches were applied inline in the source and
>was a native package, so I didn't have a diff.gz to look for our patches.
>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
>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
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
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
More information about the Ubuntu-motu-mentors