Bug#741573: Proposed draft of ballot to resolve menu/desktop question
Le Sun, Aug 16, 2015 at 05:54:50PM +0200, Didier 'OdyX' Raboud a écrit :
>
> 3. We recommend that the maintainers of the 'menu' package update
> that package to reflect this increased focus on .desktop files
> by modifying the 'menu' package to use .desktop files for the
> source of menu information in addition to menu files.
Hi Didier and everybody,
I think that option D has two fundamental flaws and I would like to recommend
the TC against voting for it.
* First, if it is voted, nothing will happen.
If the TC adopts option D, and if the maintainer (no plural) of the 'menu'
package decides to not follow point 3's recommendation, what will be the
practical difference between option D and option Z ? I voiced this concern in
2014 (741573#450), but got no answer. Who do you expect to do the work ?
The reason I ask is that option D carries nothing new. In 2008, we already
had a discussion which outcome was very similar to what is proposed in option D.
https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
Nothing happened in 5 years, in my opinion because a) the Debian menu system
is written in C, which does not help for attracting propositions of patches,
and b) its maintainer is obviously hostile to change.
* Second, it does not solve the problem that I sumbitted to the TC.
See in particular Josselin's objection in 741573#405 and Keith's answer:
Josselin:
"One of the problems I have with your proposal, compared to Charles’ original
patch, is that it encourages maintainers of hundreds of (IMHO useless) menu
files to port them to the desktop format."
Keith:
Yeah, there are a lot of inappropriate entries in my /usr/share/menu
directory. Can we fix policy to weed these out? The current
wording in §9.6:
All packages that provide applications that need not be passed any
special command line arguments for normal operations should
register a menu entry for those applications.
seems problematic to me -- it seems to require menu entries for things
as diverse as a web browser and a python interpreter. Coming up with
wording that encourages only programs which are conventionally used in
interactive mode to be included seems like a good fix here.
Option D exactly brings use back to the original problem, without solving it !
Please remember that the title of the bug where the dispute stems is : "soften
the wording recommending menu files". In that sense, the format of the menu
files does not matter. What Bill opposes with his trench war and delay tactics
is the modification of §9.6 above. Option D does not contain such a change.
What will happen if option D is voted ? Nothing. In 2008, the popcon vote
score of the menu package was around 35 %, in 2014 around 25 % and now in 2015
it is around 15 %. And much of it may be just because of its dpkg trigger. If
the TC votes option D, I will be disappointed but rest assured that the issue
will not come back to the TC later again: the Debian menu will dissapear
eventually by itself.
The problem here is our inability to face the facts and accept to change the
Policy to fit the reality. This is what I asked the TC for.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: