Ian Jackson <ijack...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnv4f06p....@windlord.stanford.edu