Bug#741573: Two menu systems
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.
Reply to: