[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#741573: Two menu systems



Russ Allbery writes ("Bug#741573: Two menu systems"):
> So, I think the questions before the TC are:
> 
> 1. Should programs that make sense in the context of a typical DE (I
>    realize there's some fuzziness around this) all have desktop files?  If
>    so, what level of Policy requirement should that be?  (Please be more
>    specific than "should" -- maybe talk in terms of expected bug
>    severities?  For reference, I consider man pages and doc-base
>    integration to be a wishlist bug.)
> 
> 2. What level of Policy requirement is providing traditional menu files in
>    individual packages, using the same terminology?

Yes.

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.

Some maintainers leave some bugs open a long time as "wishlist
wontfix" rather than simply closing it - that provides a way, for
example, to provide information to people who newly come across the
issue.


> Things that I don't think are TC issues:
> 
> * Whether desktop files should be documented in Policy at all.  There
>   appears to be consensus that they should be, and I don't think anyone is
>   disagreeing with that consensus, so there is no dispute there.

Yes.  I think the TC resolution should explicitly state, though, as a
matter of opinion, that the TC thinks it entirely reasonable that
desktop files should be documented in policy.

> * How Policy should formally represent the distinction between different
>   levels of requirements.  I respectfully suggest that this is a question
>   of the maintenance and style of the Policy documentation, not a question
>   of technical policy for the project, and is therefore a matter for the
>   Policy Editors to decide, not the TC.  What we're looking for from the
>   TC is clear guidance on what the requirements are and what level of
>   severity those requirements have.  We clearly need to find some way to
>   represent that in English once we have that guidance, but I don't think
>   this is the place to decide how to do that or what the implications are
>   for all the other "should" statements in Policy.

I'm very happy to leave that to the policy team.  The TC resolution
should explicitly say that that's what we're doing.

Ian.


Reply to: