Bug#741573: Two menu systems

[Russ Allbery <rra@debian.org>]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I think that all of these features (desktop files, trad menu entries,
> manpages and doc-base bugs) should have the same status.

> I would describe that status like this:

>  * A maintainer should not be criticised for uploading a package
>    without the feature.

>  * Contributions to provide the feature are encouraged.

>  * A maintainer should accept a patch which provides the feature
>    (unless there is something specifically wrong with the patch).

>  * In particular a maintainer should not decline such a patch on the
>    grounds that they think the feature is not important or does not
>    justify the effort of merging (and if necessary carring) the patch.

>  * lintian ought to report the lack of the feature as a warning
>    (supposed lintian can determine reasonably accurately whether the
>    feature is applicable to the package).

> I'm not sure that bug severity is a particularly good way of encoding
> this kind of information.  Maintainers have different approaches to
> bug severity and in general what a particular severity "means" (at
> "normal" or below at least) is generally up to the maintainer.

> Having said that I don't think "wishlist" is quite right for this.  I
> think "minor" is closer.  I think that for a wishlist bug a maintainer
> might reasonably decline a contributed patch on even fairly minimal
> grounds.

For the Lintian tag severity, minor/certain translates into a warning.
Anything less than that translates to an info (I) tag.

# Map severity/certainty levels to tag codes.
our %CODES = (
    pedantic  => { 'wild-guess' => 'P', possible => 'P', certain => 'P' },
    wishlist  => { 'wild-guess' => 'I', possible => 'I', certain => 'I' },
    minor     => { 'wild-guess' => 'I', possible => 'I', certain => 'W' },
    normal    => { 'wild-guess' => 'I', possible => 'W', certain => 'W' },
    important => { 'wild-guess' => 'W', possible => 'E', certain => 'E' },
    serious   => { 'wild-guess' => 'E', possible => 'E', certain => 'E' },
);

So if you feel like these are minor bugs (and that sounds about right to
me), they would naturally end up as warning Lintian tags provided that
Lintian can reliably detect the absence.  But that's a big caveat; see
below.

Note that your feel for the severities isn't currently what Lintian
implements.  Missing man pages are currently marked as a normal bug.  If
they were marked as minor, they would drop to an I tag, since Lintian
can't reliably determine whether a man page is present (due to man pages
provided by separate arch: all packages and a dependency).

Missing doc-base registration is currently wishlist/possible (same problem
on certainty).  I don't believe there is any Lintian diagnosis for missing
menu integration, nor (intentionally) for a missing desktop file since
it's not clear whether a given package should have a desktop file, given
the desired integration criteria.  It would be tricky to diagnose this in
Lintian, since there are a lot of binaries in /bin and /usr/bin that
should not have any sort of menu integration.  Consider pkg-config, for
example.

So... I'm a little dubious of your desire for all of this to be Lintian
warnings, since I don't think that matches Lintian's current criteria for
warnings, but I do think that the severity of the missing man page Lintian
warning may be a little overstated at the moment.  I have no idea how one
would go about writing an effective Lintian check for missing menu
integration without forcing a ridiculous and undesireable number of
overrides.

In general, I like your breakdown of expectations about maintainer
behavior.  This feels like some sort of "desired feature" level of Policy
description, which would fall between should and may.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>