I have a very different take on this to Russ. We currently have two menu systems. I'm going to call them the "trad" and "desktop" menus.
They have the following very important differences (some of these are matters of opinion, but I will take what appear to me to be the opinions of their respective maintainers): Scope: The trad menu is supposed to contain pretty much everything that can be executed, including command-line programs (to be run via a terminal). For example, bc has a trad menu entry. Conversely, the desktop menu is supposed to contain only a subset of programs that are considered useful for users to find and invoke via a menu. Organisation/categorisation: Both the trad and desktop menus have had effort put in by their respective maintainers into organising the menus into subheadings etc. However, these categorisations are different. Consumers: The trad menu is already consumable by a very wide range of window managers etc.; the desktop menu is consumed primarily by desktop environments. Technology: The two systems have different file formats. While the semantics of the information presented overlap, there are substantial differences in the capabilities of the two systems. The trad menu makes lower demands on menu entry consumers, and conversely imposes more restrictions on menu entry providers. The desktop menu gives more flexibility for menu entry providers, and consequently is harder to support as a menu consumer. Both menu systems have sufficient supporters and users that they are independently viable projects. Some people will say that the trad menu is dead and no-one uses it, but that's clearly not true. Consider the package http://qa.debian.org/popcon.php?package=menu-xdg which provides a view of the trad menu in desktop system which supports the desktop (XDG) menus. It therefore seems to me that the correct approach is to continue to support and develop both these systems. Given the historical conflict between the maintainers of the two systems, we need to lay down clear boundaries. In the spirit of do-ocracy, decisions about each menu system should be made by its respective sets of maintainers. So each menu system's maintainers should: * Determine the technical and social policy for their own menu system (subject to the usual review); * Decide for their own system whether a particular package should have an entry in that menu. (Initially, such decisions would be made by the package maintainer of course, guided by policy); * Decide how that menu entries should be categorised; * Decide if and when to make changes to their file format and infrastructure, including developing appropriate transition plans etc. I.e., each menu system's maintainers and proponents should be enabled to do the work they want to do, to make the menu system that they prefer be as good as it can be. No-one should block their work or nonconsensually deprecate it. My conclusion is: * Debian policy should contain two sections on menus. * Section on the trad menu should say what it currently says. In particular, it should continue to say that pretty much all relevant packages should provide trad menu entries. Failure to provide a trad menu entry (when the trad menu maintainers would like such a menu entry to exist) is a bug. * Section on the desktop menu should say whatever the desktop people think is appropriate, including descriptions of file formats, when and how to categorise entries, etc. As above, failure to provide a desktop menu entry when the program is covered by the guidelines would be a bug. As a consequence, many maintainers will need to provide both files in their output binary packages. This is by no means an unreasonable burden on individual package maintainers. No-one is suggesting that failing to provide a menu entry would be an RC bug. We should treat this the same way we treat lack of a manpage: there are plenty of packages in Debian with no manpages. But we expect that if someone who is keen on manpages writes a manpage, the package maintainer will take the patch. (And the risk with manpages, that they become out of date, doesn't really apply for menu entries.) A maintainer of a package which wants to be in both menus might choose to put two separate menu entry source files in their source package. I think this is probably the best approach: the amount of metadata duplication involved is minimal, and having two source files avoids any possibility of irreconcilable conflict between the opinions of the two menu systems. But if a maintainer wants (for example) to generate a trad menu file from an desktop file, then that's fine. BUT this is ONLY PROVIDED that the generated trad menu file is properly confirming to the trad menu specification and has the descriptive text, categorisation, etc., preferred by the trad menu maintainers. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
