Bug#741573: Two menu systems

[Russ Allbery <rra@debian.org>]

Anthony Towns <aj@erisian.com.au> writes:

> 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.

I think this is a very good way of thinking about it.

> "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.

Well, but Policy *does* provide that sort of advice.  I've used it heavily
for exactly that sort of advice in the past.  One could argue that this is
really the domain of the Developers' Reference, but the distinction isn't
all that sharp.

Policy is primarily a descriptive document (here's how our integrations
function) and secondarily an aspirational document (here's what a
well-designed Debian package should look like).  It isn't really the
document that defines consequences for non-compliance, although it's
closely linked via the must directives.  That's the release criteria,
managed by the release team.  Although I suppose to some extent it defines
what bugs can't be closed without fixing them.

> 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?

It's somewhat unrelated to this particular bug, but I think it's important
to not overstate the severity of certain problems.  Those of us who have
been working on Debian for a long time have a feel for what stuff "really
matters" and what stuff is "nice to have," but new contributors don't, and
right now the requirements are daunting and intimidating.  Ideally, the
must/should/desired language should provide a bit more of a guide to what
things are vital, what things should be worked on second, and what things
are quality of packaging issues.

In practice, we treat man pages more as a quality of packaging issue than
as part of that set of stuff you should work on second.  So I think
classing them as part of that quality of implementation group would be
doing what Policy always does: trailing and documenting project consensus.

> "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

So we're converging on something in the normal to wishlist range.  :)
That's partial consensus, at least.

> 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...

I'm not happy with going so far as to say that they should not be present.
In general, if someone wants to maintain some piece of functionality in
Debian and feels like it's useful, we should not actively undermine that.
People may not collaborate to a degree that makes that work possible, and
they may have to be persuasive, but that's different from actively
rejecting the work.

I think the main question here is whether, from a Policy perspective,
traditional menu entries should remain in the quality of implementation
bucket or fall out of it into the "one of those things that's in Debian
but that is strictly optional" buckets.  That seems to be the root of the
disagreement.

Multiple people have stated that they like the traditional menu and care
about that integration, which is generally a good argument for keeping
something in the quality of implementation bucket.  On the other hand, I
still can't shake the feeling that the menu systems substantially
duplicate each other, and having to maintain separate configuration for
both of them feels irritating in a way that's disproportional to the
amount of work involved.  So I'm somewhat skeptical that both systems will
be maintained going forward to a sufficient degree to stay useful.

*If* we have to choose, I think the desktop menu is more useful to more of
our users.  Maybe that's just a false dichotomy and I'm borrowing trouble,
though.

> 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.

That seems to roughly correspond to my categories above.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>