Russ Allbery writes ("Bug#741573: Two menu systems"): > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > IMO if those patches aren't unreasonable then maintainers should accept > > them, even if they're slightly less automatic than would be ideal. > > Sure. I don't think anyone anywhere in this discussion was advocating > rejecting contributed traditional menu entries in packages.
I did some searches for bugs where trad menu entries or improvements were rejected by maintainers. I found a great many bugs where trad menu entries were supplied by a variety of contributors, and accepted by maintainers. I did find three which are arguably recalcitrant maintainers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738027 But this is a gratifyingly low level of obstruction. > I do think that "should" in Policy is stronger than that, and I don't > think just weakening "should" for all of Policy is the right solution to > this bug. I also don't know if Bill would be happy with a weaker version > of "should" that's akin to how we handle man pages in practice. I think the best approach would be to make it clear somewhere in the introduction to the policy manual that the maintainer can reasonably decide that a package is acceptable even though it fails to comply with a "should". That's not to say that tools like lintian shouldn't warn about the lack of menu entries the same way they warn about lack of manpages. > I think doc-base integration is a fairly similar case, BTW. In that case, > Policy says that it is "recommended practice," which policy defines as > equivalent to "should." If anything, doc-base is probably less used by > end users than the traditional menu. (Personally, I think man pages are > more important than either, but man pages are also more work, and that's > to some extent personal preference.) Right. I think this bolsters my line of argument that policy already uses "should" in exactly the sense which is appropriate for the Debian menu. > I don't think anyone previously has laid out the two systems the way > that you did as having far different content *by design* instead of > just by accident. I certainly hadn't been thinking of it that way. It seemed obvious to me after reading the bug log, which contains conflict not just about file format and technicalities, but also about the purpose and desired content of the menu system. Of course the participants in the discussion were approaching the discussion on the basis that they are arguing about what the assumed single menu system should be like. But it seems to me that we can give everyone what they want by explicitly saying that these two systems should coexist. Of course a flipside is that it should be straightforward to cause the trad menu to be accessible via a desktop system's menu, even if the desktop system hides it by default. I don't think anyone disputes this either, though. > That may be an interesting way forward and remove a lot of tension. The > traditional menu would be for absolutely everything and the kitchen sink, > and desktop files would only be for programs that have reasonable > integration into a more typical GUI environment. Right. > I think drawing that distinction clearly in Policy (which it does not > currently, since it doesn't mention desktop files at all, and which I > don't think the proposed patch does either) would provide a lot more > guidance about what people should do in practice and also provide more > explicit blessing for window manager packagers who aren't interested in > the all-encompassing menu to drop it (at least by default). That might be > a useful way to resolve this conflict and put to rest the periodic > arguments about whether, say, shells should have menu entries. They would > have traditional menu entries but not desktop files, and we could say that > explicitly. Exactly. I think the best way to deal with this is to have two separate policy sections, one for each menu system. That way there won't have to be any disputes about what the text ought to say. Each of those two sections should use the same "should provide" wording, qualified by the appropriate explanation of the intended scope of that menu. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org