Package: debian-policy
Version: 2.5.1.0
Severity: wishlist
Ok, so maybe we need to make some changes to the menu heirarchy. But
that's not important now. Anyone who was holding his breath, waiting
for me to release a great restructuring of the menu heirarchy can just
stop. I'm not only NOT going to propose a great restructuring of the
menu heirarchy, but, in fact, I will probably OBJECT to any such
proposal until we deal with some of the issues below.
Debian Policy section 3.6, para 3 says:
Please refer to the <em>Debian Menu System</em> document
that comes with the <tt>menu</tt> package for information
about how to register your applications and web
documents.</p></sect>
Looking at that document, we find, in section 2.2:
Here is the <em/authoritative list of Debian's menu structure/. [...]
And other examples of what seem to be (and basically are) policy, not
technical documentation.
PROBLEM ONE: Menu policy is hard to find.
It's not real clear from the policy manual that the menu document
contains policy. Policy just says it has, "information and how
to...". But it's pretty easy to figure out "how to" from the many
examples that come with the system. And developers tend to be
roll-your-own types -- a lot of them (including the menu package
maintainer) don't even bother to install the menu package. So a lot
of developers may not even realize there *is* additional policy to be
found in the menu package.
As evidence that this is a real problem, I submit the many packages
which don't follow menu policy.
PROBLEM TWO: Menu policy is badly coupled.
If we want to change menu policy, we have to arrange to get Joost to
release a new version of the menu package. Even if the menu *program*
hasn't changed. This isn't a major problem by itself, but it makes
problem three worse. (Also, if the menu program changes, developers
have to download it *in case* there was also a policy change, even if
the developers don't use the menu system, and don't want to have it
installed.)
PROBLEM THREE: We're paralyzed by choice (everyone's got an answer)
Since we don't want to force Joost to rerelease the menu package every
few weeks, there's a strong tendency to react to all suggestions to
change the menu policy with the comment: "that's a good idea, let's
get some more suggestions together and overhaul the entire heirarchy
all at once," followed by hordes of suggestions, usually bad (I know,
I've made some bad ones myself). Then we wrangle, decide we're not
sure yet, and forget the whole matter till the next innocent
suggestion comes along, to start the whole mess over again.
Note that this problem is SO prevalent, that when Joeyh suggested
*moving* the menu policy into the main policy document, the reaction
from Wichert was, "that's a good idea, but lets overhaul the entire
heirarchy all at once, first." Pretty much missing the ENTIRE POINT
OF THE PROPOSAL! (Although, technically, I think Wichert was right,
insofar as menu policy probably shouldn't be embedded in the policy
document directly.)
I'm sorry, but we are NOT GOING to overhaul the entire heirarchy all
at once! IT IS NOT GOING TO HAPPEN. But there are a couple of fairly
important suggestions that really deserve strong consideration, and
they shouldn't have to wait indefinitely. We need to be able to make
changes when we need to make changes.
And I don't want to make Joost re-release the menu package every few
weeks, any more than any of you do.
PROBLEM FOUR: nobody agrees on everything
Believe it or not, this is not a big problem, for the most part. We
shouldn't all have to agree all at once. What we need to do is find a
way that we can get *important* changes that people *do* agree on into
menu policy without trying to get everyone agree that ok, menu policy
is done, it's perfect, every change we might want to make is there.
Menu policy *needs* to be flexible. It shouldn't change *all* the
time -- I'd object to that as much as anyone. Changes should be made
only after careful consideration. But we still need to be able to
make *some* changes, and we need to be able to make them when we need
them. We need to make this NOT BE an all-or-nothing proposition. We
need a more open ended system.
The fact that nobody agrees on everything is only a problem because we
keep waiting for everyone to agree. We need to stop waiting.
- - - - - - - - - - - - - - - -
PROPOSAL (1.0?):
ABSTRACT: Menu policy should be handled much like the virtual package
list. It should be separate from the main policy document (and from
the menu package), so that there are no <em>irrelevent</em> objections
to proposed changes, only relevent ones. And it should be on the web
site and in the debian-policy package, so that it's easy to find.
ONE: Change Debian Policy section 3.6, inserting a new paragraph just
before the existing paragraph three (above):
Menu entries should follow the current menu policy as
defined in the file <ftpsite>ftp.debian.org</ftpsite> in
<ftppath>/debian/doc/package-developer/menu_policy.txt</ftppath>
or your local mirror.
TWO: Create the menu_policy.txt file, using the text below. Note that
the heirarchy is the one proposed by Joey Hess, with my suggestion of
"Help", which he seconded, and someone else's suggestion of
"Apps/Databases", which received a few seconds. We can make more
changes later, including possibly adding other menu policy issues,
such as icons, and whatnot, but this should do for a start.
The latest copy of this document can be found at
ftp://ftp.debian.org/debian/doc/package-developer/menu_policy.txt
If you have a package which doesn't fit within the existing menu
heirarchy, please bring it up on the debian-devel mailing list.
If you have other proposals for changing the menu heirarchy, or
making other changes to menu policy, please bring it up on
debian-policy.
Preferred menu structure
Here is the authoritative list of Debian's menu structure. Please
do not put your packages into any other sections without asking
for permission first!
Apps - normal applications
Databases - interactive database programs
Editors - text editors, word processors
Emulators - wine, dosemu, etc.
Graphics - image manipulation
Hammradio - anything relating to ham radio
Math - math related programs
Net - network programs that don't fit elsewhere
Programming - debuggers, etc.
Tools - simple apps, like clocks, that perform only one task
Technical - technical stuff
Text - text oriented tools other than editors
Shells - bash, ksh, zsh, etc.
Sound - sound players and editors
Viewers - image viewers
System - system administration and monitoring tools
Games - games and recreations
Adventure - walk around virtual space, zork, MOO's, etc
Arcade - any game where reflexes count
Board - games played on a board
Card - games involving a deck of cards
Puzzles - tests of ingenuity and logic
Sports - games derived from "real world" sports
Strategy - games involving long term strategic thinking
Tetris-like - games involving falling blocks
Toys - amusements, eye-candy, etc.
Help - programs that provide user documentation
Screen - programs that affect the whole screen
Lock - programs to lock the screen
Save - screen savers
Root-window - things that fill the root window
WindowManagers - X window managers
Modules - window manager modules
XShells - xterm and its brethern
THREE: (cleanup) remove section 2.2 from the menu documentation in the
menu package.
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or [EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
