Bug#741573: Two menu systems
On 12 April 2014 05:32, Russ Allbery <rra@debian.org> wrote:
> So, to take a step back, I think Ian is arguing that, by declaring the
> traditional menu system a "should," he's not introducing a problem into
> Policy that doesn't already exist, because our current use of "should" is
> all over the map.
I think it would be useful to look at this more from a "what are the
consequences if a package violates policy (and someone notices)?"
There are a bunch of possible consequences within Debian:
- the maintainer works out a fix and uploads it
- someone else works out a fix and files a bug
- someone NMUs the package
- the package gets removed from Debian by ftpmaster
- some tool prevents the package from building/being uploaded (eg
debhelper, lintian)
- the package doesn't get shipped in testing / stable
- someone takes over maintenance of the package
- it becomes okay to NMU the package without notifying the maintainer first
- it's okay to upgrade the bug to critical/serious/important
- it's okay to downgrade the bug to minor/wishlist
- it's okay to close the bug without fixing it
- someone files a bug
- lintian/piuparts/etc reports an error
I'd divide them up into:
- someone spends their time fixing the issue
- bad things happen to the unfixed package
- how likely someone is to notice
Obviously the most important/useful part of those is categories is
getting someone to fix the damn thing, but policy (and release
managers and ftpmaster et al) only really get to choose which bad
things happen as a consequence of non-compliance.
Perhaps there's another set of consequences along the lines of
"maintainer gets told off on irc, maintainer gets flamed on -devel,
maintainer gets a scolding by the tech-ctte, maintainer no longer gets
free valve games, maintainer gets kicked out of debian" that should be
considered; I don't think I'm a fan though.
> I agree with that statement as far as it goes, but I don't think it's a
> very useful observation. Because usage of "should" is currently all over
> the map, it doesn't provide any clear guidance to the packager, which is
> what the goal should be.
"Providing guidance to the packager" sounds to me more like the first
group of advice "here's what's important, here's where you should be
spending your time to make the most effective contribution to
producing a universal free operating system". I think policy's usage
of "should" doesn't provide that sort of advice because policy's just
not designed for that.
> When working on a section of Policy, I try to fix issues like that when we
> see them. There are various "should" requirements in Policy that I think
> are actually wishlist bugs, among them man pages and doc-base integration.
Not having a manpage has traditionally been treated as a real bug,
just not an especially high-priority one. What benefit would changing
this actually have?
I could certainly imagine, say, the DPL and others coming up with a
prioritised list of Things To Do that would make Debian way better;
but I don't think it's really policy's job to decide "oh, manpages
aren't important any more, .desktop files are where it's at".
Everything in /usr/bin should have a manpage, everything that should
show up in desktop menus should have an appropriate menu file. Not
having them is a bug, with all that entails, though not severe enough
to warrant dropping the package entirely. But that's as far as policy
should go -- Debian has lots of bugs, which ones get fixed first is an
entirely separate matter.
> 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?
"should" is still defined in terms of expected bug severities, isn't it?
These classifications are roughly equivalent to the bug severities
_serious_ (for _must_ or _required_ directive violations), _minor_,
_normal_ or _important_ (for _should_ or _recommended_ directive
violations) and _wishlist_ (for _optional_ items). [2]
So I would say:
- yes, they should
- the consequence of not having them should be a normal severity bug
- lack of a .desktop file shouldn't result in the package being
dropped from testing etc
- NMU policy for adding .desktop files should be decided outside of -policy
> 2. What level of Policy requirement is providing traditional menu files in
> individual packages, using the same terminology?
I don't see the value in the traditional menu -- from Ian's mail:
"The trad menu is supposed to contain pretty much everything that can
be executed, [...]. 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."
If the desktop menu already contains everything that's useful for
users to find and invoke via a menu, then everything additional that
the trad menu does is by definition useless (for users who want to do
menu things, anyway)... And if it's changed so it doesn't do anything
additional, what's the point?
So based on that I would say:
- requirement that they should *not* be present
- consequence of having them should be a minor bug
But I don't even know if I'm using desktop menus or trad menus, so...
> * How Policy should formally represent the distinction between different
> levels of requirements.
FWIW, I think policy should be distinguishing whether its
recommendations are requirements for distribution (legal issues,
dependency errors), proper practice (ie, it's a bug if you don't do
this), or just a good idea to consider (a suggestion from experienced
developers/packagers), but beyond that should just be documenting how
to make optimal packages assuming infinite time and motivation. I
don't know how you could do that more effectively; must/should/may
still seems reasonable to me, but it doesn't seem that effective.
Splitting them as three separate documents (distro/release
requirements, policy, suggested practices) might be an option. Maybe
it would be more effective to approach the problem from the other end
-- provide a document/site of what the project thinks are the most
important things to work on, so that people who want to "force"
maintainers into doing things go there rather than debating which verb
is used in policy.
Cheers,
aj
--
Anthony Towns <aj@erisian.com.au>
Reply to: