Guidelines for reviewing new packages.

[Emmet Hikory]

Emmet Hikory wrote:
>     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.

Emilio Pozuelo Monfort wrote:
>      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 actually be opposed to enforcing that rule.  There are a
number of arguments against it (see below), and while I also tend to
prefer it, I don't see value in making a fuss if the package uses bare
diff.gz.  Speaking specifically about wxwidgets2.6: that package is
very odd in many ways, of which the patching system is one of the
least confusing.  Regarding Security / SRU guidelines, I firmly
believe that whichever patch system is in use by the package should be
followed also for these updates.  Mixing pure diff.gz patches with
debian/patches patches is a recipe for confusion.

Summary arguments against the use of dpatch, etc.
A)  It can be frustrating to generate the built source for inspection
(IRC transcript(1))
B)  It prevents the use of complex grep to test for security issues
(except after (A))
C)  Packages maintained in VCS with full source do not benefit from
VCS merging when pulling new upstream.
D)  Users cannot as easily apply alternate-source patches if wishing
to modify source (without learning distribution-specific patch
systems).
E)  Lack of care with foo-edit-patch can cause patches of patches of
patches of ...

    Now, just because I do happen to be a fan of patch systems,
despite defending the option of not using them:

Summary arguments in favor of a patch system:
A)  It is much easier to understand each change atomically
B)  dpatch comments are an excellent way to communicate reasoning for a patch
C)  It is easier to extract specific patches for sending upstream or
to other distributions
D)  One can easily enable / disable specific patches
E)  When packaging a new upstream, one doesn't have to dig through
patch application failures from zcat ../foo.diff.gz | patch -p1 to get
a working debian/

1: http://kitenet.net/~joey/blog/entry/dpatch_dbs_etc_etc_etc_etc_considered_harmful/

-- 
Emmet HIKORY