Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Don Armstrong]

I'm proposing the following draft ballot to resolve the menu/desktop
question. This draft is available in git; feel free to make specific
changes there and announce them to the bug. If there is no discussion or
substantial changes to this draft, I will call for votes around Monday
the 3rd of August. If there is discussion or changes, I will delay as
appropriate.



Whereas:

1. The Debian Technical Committee has been asked to resolve a
dispute between maintainers of Debian Policy over a change that

i. incorporates the description of the FreeDesktop menu system
and its use in Debian for listing program in desktop menus
and associating them with media types

ii. softens the wording on the Debian Menu system to reflect that
in Jessie it will be neither displayed nor installed by
default on standard Debian installations.

Using its power under §6.1.1 to decide matters of technical policy:

OPTION A:

1. The Technical Committee adopts the changes proposed by Charles
Plessy in ba679bff[1].

2. Further modifications to the menu policy are allowed using the
normal policy modification process.

[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Using its power under §6.1.5 to offer advice:

1. The Technical Committee suggests that the maintainers of the
Debian menu package support translating .desktop files of
packages which do not provide menu files.


OPTION B:
1. Considers that the policy procedure resulted in consensus, and
adopts the changes proposed by Charles Plessy in ba67bff.[1]

2. Further modifications to the menu policy are allowed using the
normal policy modification process.

[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

OPTION C:

1. The Technical Committee adopts the changes proposed by Bill
Allombert.[1]

2. Further modifications to the menu policy are allowed using the
normal policy modification process.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446

OPTION Z:

Further discussion
--
Don Armstrong http://www.donarmstrong.com

The attackers hadn't simply robbed the bank. They had carried off
everything portable, including the security cameras, the carpets, the
chairs, and the light and plumbing fixtures. The conspirators had
deliberately punished the bank, for reasons best known to themselves,
or to their unknown controllers. They had superglued doors and
shattered windows, severed power and communications cables, poured
stinking toxins into the wallspaces, and concreted all of the sinks
and drains. In eight minutes, sixty people had ruined the building so
thoroughly that it had to be condemned and later demolished.
-- Bruce Sterling, _Distraction_ p4

[Sam Hartman]

Unless someone objects
I propose that the following text also be included in option b:

Using its power under §6.1.5 to offer advice:

1. The Technical Committee suggests that the maintainers of the
Debian menu package support translating .desktop files of
packages which do not provide menu files.


I'd like to be able to vote on that option, but I suspect there's no one
who favors B who doesn't favor that text.

[Don Armstrong]

Post by Sam Hartman
Unless someone objects
1. The Technical Committee suggests that the maintainers of the
Debian menu package support translating .desktop files of
packages which do not provide menu files.
I'd like to be able to vote on that option, but I suspect there's no one
who favors B who doesn't favor that text.

Sounds good to me; added.
--
Don Armstrong http://www.donarmstrong.com

Junkies were all knitted together in a loose global macrame, the
intercontinental freemasonry of narcotics.
-- Bruce Sterling, _Holy Fire_ p257

[Didier 'OdyX' Raboud]

Post by Don Armstrong

Post by Sam Hartman
Unless someone objects
1. The Technical Committee suggests that the maintainers of the
Debian menu package support translating .desktop files of
packages which do not provide menu files.
I'd like to be able to vote on that option, but I suspect there's no
one who favors B who doesn't favor that text.

Sounds good to me; added.

Are we somehow stuck on this issue?

I unfortunately missed yesterday's TC BoF @DebConf, but what I got from
the video and re-reading the last meetings' minutes (which I also
missed, bummer), it appears to me that we have a "orientation" conflict,
which I'll try to phrase as I understand it:

The current ballot [dla_draft.txt] focuses on deciding between two
outcomes of the policy process (AB vs C), with two "flavours" (A vs B)
to actually let us decide whether to explicitely say that we consider
that the process reached consensus. I understand this ballot as the
result of the TC (arguably pushed in this direction by some of its fresh
members) re-focusing the issue on the process question, rather than the
technical question. As I undertand it, Steve is unhappy with this
ballot.

On the other hand, we have Keith's proposal [keithp_draft.txt] that
explicitely doesn't address the "process question", but comes with an
explicit technical decision (roughly saying "where a 'menu' entry was
needed, this should be a .desktop; 'menu' should use .desktop"). As I
understand the situation, Sam is unhappy with this ballot.

So, how do we move forward with this? I've personally put some thought
to this issue, have re-read all drafts, and, although I very much
appreciate Sam's approach and agree with his "consensus achievement"
conclusions, I now think that Keith's proposal is technically an "even
better" solution than the original "consensually achieved" solution.
That said, picking Keith's option doesn't let us (modulo new amendments)
explicitely give our opinion on how the process worked, but I'm starting
to think that this might be a good thing, in the end.

What about "just" adding Keith's proposal to the ballot, and let the
Condorcet magic act?

Cheers,
OdyX

[dla_draft.txt] http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/dla_draft.txt
[keithp_draft.txt] http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/keithp_draft.txt

[Don Armstrong]

Post by Didier 'OdyX' Raboud
What about "just" adding Keith's proposal to the ballot, and let the
Condorcet magic act?

This has sort of been my plan; I just have not had enough spare cycles
in the past few weeks (grant deadlines) to have the time necessary to
work through Keith's plan and shift it into a specific patch to policy.

If someone else wants to take this on and run with it, I'd appreciate
that. Otherwise, I'll hopefully get to it in the next two weeks.

[Sam Hartman]

Post by Didier 'OdyX' Raboud
What about "just" adding Keith's proposal to the ballot, and let
the Condorcet magic act?

Don> This has sort of been my plan; I just have not had enough spare
Don> cycles in the past few weeks (grant deadlines) to have the time
Don> necessary to work through Keith's plan and shift it into a
Don> specific patch to policy.

If you add Keith's proposal as well as an explanation of our technical
objection to what debian-policy came up with it, I might even vote for
it.

If you were to add a recommendation to ballot option B that under 6.1.5
we ask debian-policy to consider Keith's proposal, I'd prefer that to
the current text.

If you simply add a ballot option for Keith's proposal without text in
the decision explaining our technical objection to option A/B, I'll
disagree with it as strongly as I can. (Read, I'd probably feel
strongly enough to fight the issue in other fora if I was in the rough
here).
While we're not overturning anything in the sense of an override here, I
think we owe an explanation for our actions, and I feel really strongly
about that.

[Don Armstrong]

Post by Sam Hartman

Post by Didier 'OdyX' Raboud
What about "just" adding Keith's proposal to the ballot, and let
the Condorcet magic act?

Don> This has sort of been my plan; I just have not had enough spare
Don> cycles in the past few weeks (grant deadlines) to have the time
Don> necessary to work through Keith's plan and shift it into a
Don> specific patch to policy.
If you add Keith's proposal as well as an explanation of our technical
objection to what debian-policy came up with it, I might even vote for
it.

This is my plan. The proposal needs to be written up as a specific patch
to policy, with a separate rationale, and then we can actually vote on
it as a separate option in the ballot.

I'm trying to find some spare cycles to work on this in the next two
weeks, but if someone beats me to it, excellent.

Post by Sam Hartman
If you were to add a recommendation to ballot option B that under
6.1.5 we ask debian-policy to consider Keith's proposal, I'd prefer
that to the current text.

If no one gets around to handling the above, that might be what we have
to do.

[...]

Post by Sam Hartman
While we're not overturning anything in the sense of an override here,
I think we owe an explanation for our actions, and I feel really
strongly about that.

Ideally the patch and its rationale should stand alone without the need
for a separate text. But that said, if you disagree that the rationale
is not sufficient once it exists, I'll either try to modify it or draft
a separate text.

[Didier 'OdyX' Raboud]

Post by Don Armstrong

Post by Sam Hartman

Post by Didier 'OdyX' Raboud
What about "just" adding Keith's proposal to the ballot, and let
the Condorcet magic act?

Don> This has sort of been my plan; I just have not had enough spare
Don> cycles in the past few weeks (grant deadlines) to have the time
Don> necessary to work through Keith's plan and shift it into a
Don> specific patch to policy.
If you add Keith's proposal as well as an explanation of our
technical objection to what debian-policy came up with it, I might
even vote for it.

This is my plan. The proposal needs to be written up as a specific
patch to policy, with a separate rationale, and then we can actually
vote on it as a separate option in the ballot.

I'm not convinced: I see Keith's proposal as "TC setting technical
policy without actually phrasing the detailed patch for the Debian
Policy document" as a fine course of action for us to take. Actually,
I'm afraid that crafting the detailed Policy patch would put the
concerned sections of Policy under some sort of "TC dome", which I don't
see as a desirable outcome.

Formulated differently, I prefer deciding on a technical _choice_ rather
than a detailed Policy patch. ABC options are to be seen differently, as
they are pre-existing Debian Policy patches. Finally, I really have a
hard time seeing how crafting a Debian Policy patch ourselves doesn't
fall under §6.3.5 "no detailed design work - The TC does not engage in
design of new (…) policies", whereas Keith's proposal is more clearly
§6.1.1 "decide of any matter of technical policy".

Cheers,
OdyX

[Sam Hartman]

Post by Sam Hartman
While we're not overturning anything in the sense of an override
here, I think we owe an explanation for our actions, and I feel
really strongly about that.

Don> Ideally the patch and its rationale should stand alone without
Don> the need for a separate text. But that said, if you disagree
Don> that the rationale is not sufficient once it exists, I'll
Don> either try to modify it or draft a separate text.

No, a rationale that explains why option D is better than A/B is all I'm
asking for.

[Sune Vuorela]

Post by Sam Hartman

Post by Sam Hartman
While we're not overturning anything in the sense of an override
here, I think we owe an explanation for our actions, and I feel
really strongly about that.

Don> Ideally the patch and its rationale should stand alone without
Don> the need for a separate text. But that said, if you disagree
Don> that the rationale is not sufficient once it exists, I'll
Don> either try to modify it or draft a separate text.
No, a rationale that explains why option D is better than A/B is all I'm
asking for.
From my technical POV I think Option D is better than A/B because it is a more

clear technical solution, and saying "there is one menu to care about"

The current A/B thing ended up as a standard compromise that tries to leave
everyone equally unhappy, and ending everyone having to decide for them selves
which menus to cater for.

I don't think A/B is a particular good solution but is immensely better than
doing nothing. Option D is what I was hoping for we would end up with in some
years after letting the debian menu bitrot for another couple of years.

In option D4, I'd though like if "Debian Desktop" or similar was involved, as
it is likely the debian desktop maintainers (XFCE, Plasma, Gnome, LX(DE|Qt),
..) who are closest to the users in this regard.

Post by Sam Hartman
From my social POV I'd love to see B win because I really think that there was

a good enough consensus to be able to move on with issues like that. If we
hadn't had the double-role of menu maintainer and policy editor, I'm pretty
sure we wouldn't have gotten here in the first place.

But as Debian is a technical project consisting of social individuals, I would
hope to see D>B>A>Z>C as the final result.

/Sune
- the one who initiated this mess

[Charles Plessy]

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,

[Didier 'OdyX' Raboud]

Hi Charles, and thanks for your feedback,

Post by Charles Plessy
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 disagree with this, because of the last sentence of D1, put in force
using §6.1.1 (decide on any matter of technical policy): "Applications
providing a .desktop file should not provide a Debian menu file." This
will allow maintainers that _do_ provide .desktop files to stop
providing .menu files as well.

Post by Charles Plessy
I voiced this concern in 2014 (741573#450), but got no answer. Who do
you expect to do the work ?

Either the 'menu' maintainer and/or anyone sufficiently interested in
keeping said system relevant. With D1 in place, I expect .menu files to
start disappearing from the archive at a good pace; it will become
somewhat urgent for those relying on the menu system to work towards
having this .desktop-to-menu translation infrastructure in place.

Post by Charles Plessy
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

I think it is quite reasonable to assume that Keith's proposal is a
derivative of that proposal.

Post by Charles Plessy
* Second, it does not solve the problem that I sumbitted to the TC.

The TC is currently trying to decide whether to decide on the conflict
(AB vs C) or to decide on the 'menu' matter of technical policy (D).

I honestly think all 4 options would resolve the "unresolvable conflict"
that you referred to the TC.

Post by Charles Plessy

Post by Charles Plessy
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.

I agree that the current proposition doesn't address this problem in D1,

Post by Charles Plessy
packages for which the Debian menu system currently applies should
provide a .desktop file

One key word is "currently" in there. I think it is reasonable to read
this as "run 's/register a menu entry/provide a FreeDesktop .desktop
file/g' over Policy §9.6". It would certainly not prevent further
changes to §9.6 as long as the TC decision is respected.

From what I understand of your opposition, you're afraid that further
discussions around softening the "all packages that provide applications
that need not be passed any special command line arguments for normal
operation should provide a FreeDesktop .desktop file entry for those
application" part would be met with unresolvable opposition from Bill,
right? What about the following formulation then (not yet entirely
convinced, but I hope that's a step forward)?

Post by Charles Plessy
1. The Technical Committee resolves that applications providing a
.desktop file should not provide a Debian menu file.

This would delegate the decision on which applications are supposed to
provide a .desktop file to (arguably yet another) the Debian Policy
process.

Cheers,
OdyX

[Charles Plessy]

Post by Didier 'OdyX' Raboud
Hi Charles, and thanks for your feedback,

Thanks as well for your prompt answer :) Here are a few point-to-point
comments. Altogether, I would happily support option D if it were further
amended.

Post by Didier 'OdyX' Raboud
the last sentence of D1, put in force
using §6.1.1 (decide on any matter of technical policy): "Applications
providing a .desktop file should not provide a Debian menu file." This
will allow maintainers that _do_ provide .desktop files to stop
providing .menu files as well.

Indeed, I have overlooked that important part. Sorry for this.

Post by Didier 'OdyX' Raboud
With D1 in place, I expect .menu files to
start disappearing from the archive at a good pace; it will become
somewhat urgent for those relying on the menu system to work towards
having this .desktop-to-menu translation infrastructure in place.

An alternative would be to develop support for the FreeDesktop menu on those
platforms that only have the Debian menu at the moment.

Since option D is calling for volunteer work, which may be quite unusual for
the TC, I think that it would be important that it either provides alternatives
like the one above, or explain briefly why they were not retained in the final
resolution.

Post by Didier 'OdyX' Raboud

Post by Charles Plessy
https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

I think it is quite reasonable to assume that Keith's proposal is a
derivative of that proposal.

Thanks. I would appreciate if it would be acknowledged, I am a bit academic by
training...

Post by Didier 'OdyX' Raboud
The TC is currently trying to decide whether to decide on the conflict
(AB vs C) or to decide on the 'menu' matter of technical policy (D).

In my impression, it is not a good thing to conflate two different kind of
decisions in the same vote. This said, the current portfolio of options is a
good ground for focusing on the technical aspects.

C: Status quo reaffirming the wording of the Policy and the importance of
the Debian Menu (needed even for the Python interpreter, etc).

Z: Status quo by inaction.

AB: Softening the requirement of the Debian Menu.

D: Migration to the FreeDesktop format, and therefore disparition of the Debian
Menu if nobody works on this migration.

(By the way, I am not sure how to interpret the difference between A and B.)

I have invested a lot of time on AB as I was looking for a compromise that
would satisfy broady, but as I wrote more recently, I also do not mind a more
radical outcome. I would support option D it if we resolve the the point
below.

Post by Didier 'OdyX' Raboud
From what I understand of your opposition, you're afraid that further
discussions around softening the "all packages that provide applications
that need not be passed any special command line arguments for normal
operation should provide a FreeDesktop .desktop file entry for those
application" part would be met with unresolvable opposition from Bill,
right? What about the following formulation then (not yet entirely
convinced, but I hope that's a step forward)?

Post by Charles Plessy
1. The Technical Committee resolves that applications providing a
.desktop file should not provide a Debian menu file.

This is the first half of solving the problem. The second would be to add that
the "should" requirement of the Policy's section 9.6, paragraph 2, is changed
to "may".

Have a nice day,

Charles

[Keith Packard]

Post by Charles Plessy
Thanks. I would appreciate if it would be acknowledged, I am a bit academic by
training...

The proposed ballot tries to clarify the difference between D and AB by
noting:

6. The policy change by Charles Plessy in ba679bff76[1]
would comply with this decision if it were revised to require
that no package provide a menu file when it provides a .desktop
file for the same application.

Post by Charles Plessy
I have invested a lot of time on AB as I was looking for a compromise that
would satisfy broady, but as I wrote more recently, I also do not mind a more
radical outcome. I would support option D it if we resolve the the point
below.

We certainly appreciate the work you've done on the existing policy
patch; A, B and D all incorporate that. D goes just a bit further in an
attempt to migrate to the .desktop format

Post by Charles Plessy
This is the first half of solving the problem. The second would be to add that
the "should" requirement of the Policy's section 9.6, paragraph 2, is changed
to "may".

Reading from the ballot again:

2. Packages may provide menu files at the pleasure of the
maintainer, but packages providing a .desktop file shall not
also provide a menu file for the same application.

Thinking about this tonight, I've rewritten option D as AB + patch.

As you can see, this makes packages shipping menu and .desktop files for the same
application buggy, makes all packages using the Debian Menu System
buggy, and advises that the Debian Menu System be changed to read both
menu and .desktop files.

I think the following version is functionally equivalent to the existing
option D, and makes it clear that we're trying to take your suggestion
and push further in the same direction.

OPTION D':

Using its power under §6.1.1 to decide on any matter of technical
policy, and its power under §6.1.5 to offer advice:

1. The Technical Committee adopts the changes proposed by Charles
Plessy in ba679bff[1].

2. In addition to those changes, the Technical Committee resolves
that packages providing a .desktop file shall not also provide a
menu file for the same application.

3. We further resolve that "menu programs" should not depend on the
Debian Menu System and should instead rely on .desktop file
contents for constructing a list of applications to present to
the user.

4. We advise the maintainers of the 'menu' package to 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.

5. Discussion of the precise relationship between menu file
section/hints values and .desktop file Categories values may be
defined within the Debian Menu sub-policy and Debian Menu
System.

6. Further modifications to the menu policy are allowed using the
normal policy modification process.

[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

[Charles Plessy]

Post by Keith Packard
Thinking about this tonight, I've rewritten option D as AB + patch.
Using its power under §6.1.1 to decide on any matter of technical
1. The Technical Committee adopts the changes proposed by Charles
Plessy in ba679bff[1].
2. In addition to those changes, the Technical Committee resolves
that packages providing a .desktop file shall not also provide a
menu file for the same application.
3. We further resolve that "menu programs" should not depend on the
Debian Menu System and should instead rely on .desktop file
contents for constructing a list of applications to present to
the user.
4. We advise the maintainers of the 'menu' package to 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.
5. Discussion of the precise relationship between menu file
section/hints values and .desktop file Categories values may be
defined within the Debian Menu sub-policy and Debian Menu
System.
6. Further modifications to the menu policy are allowed using the
normal policy modification process.
[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Thanks a lot, Keith, I think that this is much clearer and integrates very well
in the ballot.

Minor points follow, but I am happy with the current ballot and do not want
to introduce further delays.

- When I asked for acknowledgement, I was reffering not to the Policy patch,
but to the wiki page from 2008 <https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries>.
However, if option D' does not contain anymore the transition plan of option D,
there is no need to mention the wiki page anymore.

- Since the only difference between options A and B is a statement on the
Policy process that is orthogonal to the technical decision on the menu, I
would recommend to just drop option B. This is in line with the fact that
option D' here is following A.1 and not B.1.

Have a nice day,

Charles

[Didier 'OdyX' Raboud]

Post by Keith Packard
Thinking about this tonight, I've rewritten option D as AB + patch.
As you can see, this makes packages shipping menu and .desktop files
for the same application buggy, makes all packages using the Debian
Menu System buggy, and advises that the Debian Menu System be changed
to read both menu and .desktop files.
I think the following version is functionally equivalent to the
existing option D, and makes it clear that we're trying to take your
suggestion and push further in the same direction.

Thanks for this re-phrasing; I feel it puts all available options on a
comparable scale.

Post by Keith Packard
Using its power under §6.1.1 to decide on any matter of technical
1. The Technical Committee adopts the changes proposed by Charles
Plessy in ba679bff[1].

This diff contains the following phrase:
+ Packages can, to be compatible with Debian additions to some window
+ managers that do not support the FreeDesktop standard, also provide a
+ <em>Debian menu</em> file, following the <em>Debian menu policy</em>,
+ (
)

Post by Keith Packard
2. In addition to those changes, the Technical Committee resolves
that packages providing a .desktop file shall not also provide a
menu file for the same application.

Thinking about the various options on the table again, I was initially
puzzled whether voting D{,'} would be a better policy than AB, in
particular from the perspective of trad-menu users and developers.

The problem with option A from this perspective is that it demotes the
constraint for trad-menu entries to a "can": absence of these entries
would be a wishlist / minor bug and it is likely that very few new menu
entries would enter the archive, and that some maintainers would prefer
to drop them entirely (along with the xpm icons) at the first bug in
them. This would lead to a degradation of the quality and relevance of
the trad-menu database over time.

With the (arguably strong) additional changes in ballot options D{,'}
the trad-menu entries become undesired in presence of XDG menu desktop
files, and there's additional advice to the trad-menu developers (both
in the ballot as well as in this thread, by various people) on how the
trad-menu ecosystem could be enhanced to take better advantage of the
new state of things. Of course, this implies that some work will need to
be put in the trad-menu programs and tools, but if the advice to use the
XDG menu desktop files as source is followed, then the quality and
relevance of the trad-menu database will _increase_ over time.

On the other side, without people to put up this work, picking D will
most certainly lead to the disappearance or irrelevance of the trad-menu
ecosystem. Given the prevalence of the XDG menu nowadays as well as the
shortcomings of the trad-menu, I am personally fine with taking this
risk: the burden of keeping the trad-menu relevant would be (IMHO
correctly) put on people who care about it, instead of leaving it on all
package maintainers through the Debian Policy.

Finally, although I do understand how people interested in the trad-menu
would feel about getting forced to work (through an ecosystem change) in
a direction they might not have planned or even wanted, I do think that
the evolution of the wider menus ecosystem (both trad- and XDG-) needs
to be reflected in our technical policy, and that choosing the most
complete and modern format as base (as well as ruling out double-source
for metadata) is really the sanest technical choice.

Cheers,
OdyX

[Sam Hartman]

Keith> Thinking about this tonight, I've rewritten option D as AB +
Keith> patch.

Keith> As you can see, this makes packages shipping menu and
Keith> .desktop files for the same application buggy, makes all
Keith> packages using the Debian Menu System buggy, and advises that
Keith> the Debian Menu System be changed to read both menu and
Keith> .desktop files.

Keith> I think the following version is functionally equivalent to
Keith> the existing option D, and makes it clear that we're trying
Keith> to take your suggestion and push further in the same
Keith> direction.

Keith> OPTION D':

I ask you to retain the following two paragraphs that explain why we
prefer option D should we adopt this:
The Technical Committee has reviewed the underlying technical
issues around this question and has resolved that Debian will be
best served by migrating away from our own Debian Menu System and
towards the common Freedesktop Desktop Entry Specification, and
that menu information for applications should not be duplicated in
two different formats.

To encourage this change, we make menu files optional, ask that
packages include .desktop files as appropriate and prohibit
packages from providing both menu and .desktop files for the same
application.

(I've corrected the spelling of encourage)

Keith> Using its power under §6.1.1 to decide on any matter of
Keith> technical policy, and its power under §6.1.5 to offer advice:

Keith> 1. The Technical Committee adopts the changes proposed by
Keith> Charles Plessy in ba679bff[1].

Keith> 2. In addition to those changes, the Technical Committee
Keith> resolves that packages providing a .desktop file shall not
Keith> also provide a menu file for the same application.

Keith> 3. We further resolve that "menu programs" should not
Keith> depend on the Debian Menu System and should instead rely on
Keith> .desktop file contents for constructing a list of
Keith> applications to present to the user.

Keith> 4. We advise the maintainers of the 'menu' package to
Keith> update that package to reflect this increased focus on
Keith> .desktop files by modifying the 'menu' package to use
Keith> .desktop files for the source of menu information in addition
Keith> to menu files.

Keith> 5. Discussion of the precise relationship between menu
Keith> file section/hints values and .desktop file Categories values
Keith> may be defined within the Debian Menu sub-policy and Debian
Keith> Menu System.

Keith> 6. Further modifications to the menu policy are allowed
Keith> using the normal policy modification process.

Keith> [1]:
Keith> http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479


With those two rationalle paragraphs restored I support the reworded
option D and would rank it in the same place as the existing option D.
With them removed, I would rank D below FD.

[Keith Packard]

Post by Sam Hartman
I ask you to retain the following two paragraphs that explain why we
The Technical Committee has reviewed the underlying technical
issues around this question and has resolved that Debian will be
best served by migrating away from our own Debian Menu System and
towards the common Freedesktop Desktop Entry Specification, and
that menu information for applications should not be duplicated in
two different formats.
To encourage this change, we make menu files optional, ask that
packages include .desktop files as appropriate and prohibit
packages from providing both menu and .desktop files for the same
application.

Yes, we would want that as part of any published decision. Thanks for
the clarification.

Do you think the reworded version is easier to understand in the context
of the overall process? That was my major concern here.

[Sam Hartman]

Keith> Do you think the reworded version is easier to understand in
Keith> the context of the overall process? That was my major concern
Keith> here.

I think a bit.
My big question is whether you think we'd still be able to call for a
vote tomorrow if we make this change.

I think we're well into the point of diminishing returns (which is why i
won't drop option B--I don't think we need it but I so don't want to
have to redo the vote because someone other than me wanted it and we
remove it from the ballot)

So, my recommendation is if you still feel comfortable with me making a
CFV tomorrow push the change, else do not.

[Keith Packard]

Post by Sam Hartman
I think a bit.
My big question is whether you think we'd still be able to call for a
vote tomorrow if we make this change.

I think the change has real benefit beyond simple clarification by
immediately adopting Charles' changes to policy without waiting for
further changes to that patch.

Post by Sam Hartman
So, my recommendation is if you still feel comfortable with me making a
CFV tomorrow push the change, else do not.

Given that it has the same intent, makes the inspiration for the change
clear *and* means that we'll have the bulk of the policy change adopted
immediately, I think it is worth having the new version and I have
pushed that to the repository.

[Sam Hartman]

OK.
I'd really appreciate hearing from anyone now who needs more time before
a CFV.

[Keith Packard]

Post by Sam Hartman
OK.
I'd really appreciate hearing from anyone now who needs more time before
a CFV.

I'd also love to hear back from Charles about the updated D proposal,
and whether that helps him understand what it means.

[Charles Plessy]

Post by Keith Packard

Post by Sam Hartman
OK.
I'd really appreciate hearing from anyone now who needs more time before
a CFV.

I'd also love to hear back from Charles about the updated D proposal,
and whether that helps him understand what it means.

Hi Keith and everybody,

I think that proposal D', with or without Sam's additions, makes the ballot
much more consistent than before.

Just in case it escaped your mailbox, I also wrote a slightly longer answer
yesterday.

<https://lists.debian.org/debian-ctte/2015/08/msg00074.html>

Have a nice day, and thanks for your efforts.

[Nikolaus Rath]

Post by Sam Hartman
OK.
I'd really appreciate hearing from anyone now who needs more time before
a CFV.

Please don't forget that if anyone needs more time, they can always vote
FD.

Best,
-Nikolaus

[Ian Jackson]

Responding mostly to Keith's draft from debian-ctte.git.


The Whereas leaves out a very important aspect of this. It is not
sufficient to simply decide on the file format. The primary dispute
here is not really about file formats.

The trad Debian menu is primarily curated collection of metadata,
reified as entries in individual packages' desktop files.

The trad Debian menu, and the XDG menu files as found in existing
desktop applications, do not agree on either (i) the scope of the menu
(ii) the categorisation of those applications which do appear in the
menu (iii) sometimes, the proper description of those applications.
(Let us assume for the sake of argument that there are few intentional
differences in icons.)

Indeed (ii) and (iii) follow from (i).


So the real dispute is: should the existing application metadata
database (currently represented by the Debian trad menu files in
existing packages):

(a) continue to be maintained in its existing file format

(b) be translated to a new and more modern file format
(perhaps only for some packages)

(c) be destroyed.

Given that there are people who want to maintain it, I think (c) is
unacceptable.[1]


Ian.

[Didier 'OdyX' Raboud]

Post by Ian Jackson
The trad Debian menu, and the XDG menu files as found in existing
desktop applications, do not agree on either
(i) the scope of the menu

Right. But the 'trad Debian menu' (as outlined in Policy §9.6) has never
reached the point where "applications that need not be passed any
special command line arguments for normal operation" have a menu entry.

I think this never happened mostly because having that metadata is plain
useless for vast amounts of "applications" we have under {/usr},/bin.
The other reason is also that the XDG menu has been adopted by most
major desktop environments, and is perceived as vastly more useful
(multiple sized icons, translation, etc).

Finally, my /usr/share/menu/ has _89_ entries, where I have 419 .desktop
entries under /usr/share/applications (for 4325 installed packages, and
4214 executables in /usr/bin). So, as of today, this part of policy is
de facto _not_ followed.

Post by Ian Jackson
So the real dispute is: should the existing application metadata
database (currently represented by the Debian trad menu files in
existing packages)

I disagree that this is the real dispute: today, the trad Debian menu
application metadata database is de facto already of less relevance than
the (not-in-policy) the XDG Menu, by orders of magnitude.

Post by Ian Jackson
(a) continue to be maintained in its existing file format
(b) be translated to a new and more modern file format
(perhaps only for some packages)
(c) be destroyed.
Given that there are people who want to maintain it, I think (c) is
unacceptable.

Keith's proposal doesn't imply that the trad menu would "be destroyed"
(your words), but would indeed imply that the trad menu system would
need to make use of the de-facto more relevant XDG Menu. If there are
_enough_ people that use the trad Debian menu system, I am confident
that this _will_ happen.

On the other hand, if there are not enough users and maintainers for the
trad menu, I do find it unacceptable to further impose on all
maintainers (through a Policy "should") the burden of maintaining this
redundant metadata database, which is nowadays _de_facto_ replaced by
the technically superior XDG Menu.

I think phrasing the question in terms of "there is this existing
database, how should it be transformed" is misleading, whereas I see the
question as "which metadata databases make sense for the future of
Debian".

Cheers,
OdyX

[Ian Jackson]

Post by Didier 'OdyX' Raboud
Right. But the 'trad Debian menu' (as outlined in Policy §9.6) has never
reached the point where "applications that need not be passed any
special command line arguments for normal operation" have a menu entry.

I'm not sure why you think this is relevant.

Policy says every command line program should have a manpage, but we
have many many command line programs without. That a project's
coverage isn't complete is not a reason to throw it away.

Post by Didier 'OdyX' Raboud
I disagree that this is the real dispute: today, the trad Debian menu
application metadata database is de facto already of less relevance than
the (not-in-policy) the XDG Menu, by orders of magnitude.

I don't understand why you think that something being of `less
relevance' means it should be destroyed.

Post by Didier 'OdyX' Raboud

Post by Ian Jackson
(a) continue to be maintained in its existing file format
(b) be translated to a new and more modern file format
(perhaps only for some packages)
(c) be destroyed.
Given that there are people who want to maintain it, I think (c) is
unacceptable.

Keith's proposal doesn't imply that the trad menu would "be destroyed"
(your words),

It does. There is nothing in Keith's proposal which preserves the
existing trad menu metadata. According to `apt-file search' that is a
database of 2296 menu entries (in wheezy).

Post by Didier 'OdyX' Raboud
On the other hand, if there are not enough users and maintainers for the
trad menu, I do find it unacceptable to further impose on all
maintainers (through a Policy "should") the burden of maintaining this
redundant metadata database, which is nowadays _de_facto_ replaced by
the technically superior XDG Menu.

The XDG menu database does not contain a menu entry for many things
that the trad menu does. And this is intentional. So it is not a
replacement.

Ian.

[Sam Hartman]

Ian, I'd like to encourage you to use less loaded words than "destroy."
When I hear that term and disagree with your analysis, my emotional
reaction is strong enough that I stop reading.
Your term is loaded enough that you lose the opportunity to try and get
me to think about whether you are right.
If your goal is to ask us to think about your position and engage in
reasoned discourse, you would be better served with more factual, less
emotional statements.
I understand that the emotional content is important too. I'd recommend
carrying that by talking about your own emotional state rather than
using emotional words about the concept.
For example when I heard you describe that you were so upset you needed
to leave the conversation at Debconf, I heard someone being open and
honest about how much they care about the issue.

I think I may be following what Ian's saying.


If we adopt Keith's proposal without updating policy 9.6--we retainIs
the SHOULD have menu entries for all command line apps, but move the
metadata format to .desktop, we have a number of problems. We have no
way to express the category information and some of the other metadata
from the trad menu that's kind of important for its expanded scope.

So, it's not clear what should happen.

If we revise 9.6 and adopt Keith's proposal then we're basically
adopting the XDG menu's scope, but taking away the place where the
broader information could go.

In effect we leave menu entries that do belong on the trad menu but do
not belong on the XDG menu no where.

Depending on how we do things we may also significantly complicate the
runtime dependencies of light-weight windowmanagers if we force them to
parse .desktop files and do image conversion.


In effect by adopting Keith's proposal with an update to 9.6, we're
saying that as a matter of technical policy decided by the TC, there are
some menu entries on the trad menu that do not belong on any menu at
all.

We're leaving the specifics to the individual maintainers. However, I
can see that if you value the scope of the trad menu, you'd be really
frustrated by that decision.

[Ian Jackson]

Post by Sam Hartman
Ian, I'd like to encourage you to use less loaded words than
"destroy."

I can see why you are objecting but I'm afraid I cannot see these
proposals any other way. Perhaps as you suggest it would be more
politic (more effective) to object in weaker terms.

But frankly, I am absolutely livid. It's quite an effort to write as
calmly as I am now doing.

Post by Sam Hartman
I think I may be following what Ian's saying.

I agree with what you say in this summary except that I would go

Post by Sam Hartman
If we adopt Keith's proposal without updating policy 9.6--we retainIs
the SHOULD have menu entries for all command line apps, but move the
metadata format to .desktop, we have a number of problems. We have no
way to express the category information and some of the other metadata
from the trad menu that's kind of important for its expanded scope.
So, it's not clear what should happen.

The dominant interpretation of this proposal is that that this
information should simply be removed from Debian.

Post by Sam Hartman
In effect by adopting Keith's proposal with an update to 9.6, we're
saying that as a matter of technical policy decided by the TC, there are
some menu entries on the trad menu that do not belong on any menu at
all.

Worse than that, the TC would be saying that
- the trad menu metadata database
- currently in Debian [1]
- which people have been working on for many years
- and want to keep working on
should be deleted.

"Deleted" may be "emotionally loaded" too but it is of course 100%
technically accurate, because the TC would be saying that all records
in the trad menu database, which are reified as files in source
packages in our archive, should be deleted. The files should be
deleted from the source packages and the information that was formerly
in those files would no longer appear in Debian.

I can't see a way in which that is anything but deletion, abolition,
destruction.

You may say that "destruction" has additional connotations of force,
violence, or disruption. Well, see above: the people who maintain
this database want to keep it, and as you observe it will cause
disruption.

Ian.

[1] (if only partially present, perhaps in part because of vigorous
campaigning saying it is obsolete and should be got rid of)

[Sam Hartman]

Hi.
I'd appreciate it if you would look at the restatement at the bottom and
help me make sure I'm understanding the technical implications of the
proposal we're considering.

Post by Sam Hartman
I think I may be following what Ian's saying.

Ian> I agree with what you say in this summary except that I would

Post by Sam Hartman
If we adopt Keith's proposal without updating policy 9.6--we
retainIs the SHOULD have menu entries for all command line apps,
but move the metadata format to .desktop, we have a number of
problems. We have no way to express the category information and
some of the other metadata from the trad menu that's kind of
important for its expanded scope.
So, it's not clear what should happen.

Ian> The dominant interpretation of this proposal is that that this
Ian> information should simply be removed from Debian.

That doesn't make sense to me.
Without an update to section 9.6, we're saying that we agree with the
trad menu's scope, but want the data represented in .desktop files.

I personally think that would be bad technically, but I don't see how
you get from that to "delete". You might get quickly to "the TC is
spewing nonsense because a bunch of interface work needs to be done to
make what they've asked us to do possible."
However I consider that different from "delete"

Post by Sam Hartman
In effect by adopting Keith's proposal with an update to 9.6,
we're saying that as a matter of technical policy decided by the
TC, there are some menu entries on the trad menu that do not
belong on any menu at all.

Ian> Worse than that, the TC would be saying that - the trad menu
Ian> metadata database - currently in Debian [1] - which people have
Ian> been working on for many years - and want to keep working on
Ian> should be deleted.

I don't think so.
I think we'd be saying that people should evaluate each trad menu entry
against the newly revised 9.6 and if the package maintainer believed the
information was worth keeping then it should be converted to .desktop.

I don't think you'd be happy with that result, but I think that is what
we'd be saying with Keith's draft including the section 9.6 update.

Some information would be deleted; we'd be updating the scope.
However other information would be converted.

I'm not trying to argue emotional loading here. I honestly want to know
if I'm missing something here and whether more is deleted than I expect.

[Ian Jackson]

Post by Sam Hartman
I'd appreciate it if you would look at the restatement at the bottom and
help me make sure I'm understanding the technical implications of the
proposal we're considering.

...

Post by Sam Hartman
That doesn't make sense to me.
Without an update to section 9.6, we're saying that we agree with the
trad menu's scope, but want the data represented in .desktop files.

In part, sorry, I have misunderstood. I read you as writing "_with_"
an update to 9.6.

But even reading what you wrote (sorry) it's not just a question of
scope.

It's also categorisation. The .desktop files and the menu files have
different taxonomy and I think in some cases different labelling. If
the TC says, without saying anything else, that .desktop files should
be used, maintainers will discard the taxonomy and labelling in the
menu files in favour of that already present in .desktop files.

Also, consider a maintainer of a package which currenly only has a
menu file, who is trying to conform to the new scheme. They will
probably think they are supposed to discard the menu file taxonomy in
favour of asking desktop environment teams about the proper DE
taxonomy of their program. This isn't going to work well if the DE
teams think the program shouldn't have a menu item. What is the
maintainer of `bc' supposed to do ?

Post by Sam Hartman
I personally think that would be bad technically, but I don't see how
you get from that to "delete". You might get quickly to "the TC is
spewing nonsense because a bunch of interface work needs to be done to
make what they've asked us to do possible."
However I consider that different from "delete"

This is of course another objection.

I don't think a policy update to say "use desktop files" without
specifying specific fields is a sensible idea. Perhaps the TC could
ask someone to write such a thing by saying in general terms what was
wanted.

Ian.

[Steve Langasek]

Post by Sam Hartman
If we adopt Keith's proposal without updating policy 9.6--we retainIs
the SHOULD have menu entries for all command line apps, but move the
metadata format to .desktop, we have a number of problems. We have no
way to express the category information and some of the other metadata
from the trad menu that's kind of important for its expanded scope.
So, it's not clear what should happen.
If we revise 9.6 and adopt Keith's proposal then we're basically
adopting the XDG menu's scope, but taking away the place where the
broader information could go.
In effect we leave menu entries that do belong on the trad menu but do
not belong on the XDG menu no where.
Depending on how we do things we may also significantly complicate the
runtime dependencies of light-weight windowmanagers if we force them to
parse .desktop files and do image conversion.
In effect by adopting Keith's proposal with an update to 9.6, we're
saying that as a matter of technical policy decided by the TC, there are
some menu entries on the trad menu that do not belong on any menu at
all.

If this is the message that the ballot option is sending, then I agree that
it's concerning. I'm aware there are some maintainers of desktop
environments who view this as the goal; my support for Keith's proposal was
predicated on the belief that this would /not/ be the outcome, but instead
that we were describing a path forward by which existing menu system entries
would be translated into .desktop files and the semantics would be
preserved.

The XDG .desktop format allows applications to specify that they should or
should not be shown in particular environments using the
OnlyShowIn/NotShowIn keywords. I assumed it would be straightforward to
declare a new OnlyShowIn value that menu consumers could key on if they wish
to show the traditional menu heirarchy, and that this could be implemented
without causing any problems for the existing desktop environments.

Have I overlooked something that makes this approach untenable? Should the
ballot option be extended to make this a more explicit recommendation?

[Sam Hartman]

Post by Sam Hartman
If we adopt Keith's proposal without updating policy 9.6--we
retainIs the SHOULD have menu entries for all command line apps,
but move the metadata format to .desktop, we have a number of
problems. We have no way to express the category information and
some of the other metadata from the trad menu that's kind of
important for its expanded scope.
So, it's not clear what should happen.
If we revise 9.6 and adopt Keith's proposal then we're basically
adopting the XDG menu's scope, but taking away the place where
the broader information could go.
In effect we leave menu entries that do belong on the trad menu
but do not belong on the XDG menu no where.
Depending on how we do things we may also significantly
complicate the runtime dependencies of light-weight
windowmanagers if we force them to parse .desktop files and do
image conversion.
In effect by adopting Keith's proposal with an update to 9.6,
we're saying that as a matter of technical policy decided by the
TC, there are some menu entries on the trad menu that do not
belong on any menu at all.

Steve> If this is the message that the ballot option is sending,
Steve> then I agree that it's concerning. I'm aware there are some
Steve> maintainers of desktop environments who view this as the
Steve> goal; my support for Keith's proposal was predicated on the
Steve> belief that this would /not/ be the outcome, but instead that
Steve> we were describing a path forward by which existing menu
Steve> system entries would be translated into .desktop files and
Steve> the semantics would be preserved.

Steve> The XDG .desktop format allows applications to specify that
Steve> they should or should not be shown in particular environments
Steve> using the OnlyShowIn/NotShowIn keywords. I assumed it would
Steve> be straightforward to declare a new OnlyShowIn value that
Steve> menu consumers could key on if they wish to show the
Steve> traditional menu heirarchy, and that this could be
Steve> implemented without causing any problems for the existing
Steve> desktop environments.

Steve> Have I overlooked something that makes this approach
Steve> untenable? Should the ballot option be extended to make this
Steve> a more explicit recommendation?

Since writing that message to Ian, I've thought more about this and
there's been a bit of rewording. So, I do believe that Keith's draft
more follows what you are talking about. I think that what Keith came
up with yesterday makes it clear that this is the recommended path
forward. I think that's especially true if we surface the notes in the
keith_draft.txt as you suggested in another note.

However, we're pushing a fairly harsh transition time table with the
current option D. At the same time we're recommending the trad menu
package support .desktop files, we are recommending that people pull
trad menu files from packages that also have .desktop files. That very
quickly gets you into the situation where popular applications like
iceweasel disappear from the older window managers.

Several people have expressed doubts about whether the Menu maintainer
will ever follow our recommendation (and it is only advice) to support
.desktop files.

If no one does the work, itmay be that the trad menu disappears.

I think based on comments you made in the Systemd discussion you may be
OK with that outcome: obligating people who care about the trad menu to
do the work of making it viable for Stretch, although I may be
misremembering who had what positions and your analysis may differ in
this situation.

I think option D is reasonable and will definitely vote it above FD. I
may or may not rank it first. If I do it will be exactly because we're
pushing for that transition and trying to move to one metadata format.
If I do not it will be because I think that demanding packages drop menu
files if they keep .desktop files is premature at this time.

[Josh Triplett]

Post by Steve Langasek

Post by Sam Hartman
If we adopt Keith's proposal without updating policy 9.6--we retainIs
the SHOULD have menu entries for all command line apps, but move the
metadata format to .desktop, we have a number of problems. We have no
way to express the category information and some of the other metadata
from the trad menu that's kind of important for its expanded scope.
So, it's not clear what should happen.
If we revise 9.6 and adopt Keith's proposal then we're basically
adopting the XDG menu's scope, but taking away the place where the
broader information could go.
In effect we leave menu entries that do belong on the trad menu but do
not belong on the XDG menu no where.
Depending on how we do things we may also significantly complicate the
runtime dependencies of light-weight windowmanagers if we force them to
parse .desktop files and do image conversion.
In effect by adopting Keith's proposal with an update to 9.6, we're
saying that as a matter of technical policy decided by the TC, there are
some menu entries on the trad menu that do not belong on any menu at
all.

If this is the message that the ballot option is sending, then I agree that
it's concerning. I'm aware there are some maintainers of desktop
environments who view this as the goal; my support for Keith's proposal was
predicated on the belief that this would /not/ be the outcome, but instead
that we were describing a path forward by which existing menu system entries
would be translated into .desktop files and the semantics would be
preserved.
The XDG .desktop format allows applications to specify that they should or
should not be shown in particular environments using the
OnlyShowIn/NotShowIn keywords. I assumed it would be straightforward to
declare a new OnlyShowIn value that menu consumers could key on if they wish
to show the traditional menu heirarchy, and that this could be implemented
without causing any problems for the existing desktop environments.

OnlyShowIn/NotShowIn are certainly extensible; desktop environments (or
anything else deciding whether to use a .desktop file) only look for
their own name. (Algorithm: "If an OnlyShowIn exists without my name in
it, or a NotShowIn exists with my name in it, ignore the file.") So if
you want metadata saying "only show this in a console-based menu",
OnlyShowIn=console should work fine. Or if you want to hide a menu
entry from the console, NotShowIn=console works. .desktop files also
have a "Terminal" key to say whether an application needs a tty, and
desktop environments will automatically run such applications in the
user's preferred terminal emulator.

Looking at the various metadata in the menu file format:

- "title" becomes "Name".
- "longtitle" (with some editing) becomes "Comment". Some packages
include the title in the longtitle, while others don't, so the
translation needs manual review and editing here. Also, .desktop
files will want translated descriptions (and in some cases translated
names) too.
- "package" doesn't matter for any menu entry shipped *in* the package
in question.
- "needs" becomes a combination of OnlyShowIn/NotShowIn and Terminal.
For instance, needs=text becomes just Terminal=true, though some such
entries might want OnlyShowIn/NotShowIn. needs=vc should probably
become an OnlyShowIn=console or similar, if the application actually
needs a vc (for instance, something using svgalib or fb, or something
using Linux-console-specific mechanisms). needs=[xX]11 (case varies
in practice) should become "Terminal=false"; there's an
interesting special case for applications that have both console and
graphical versions in the same binary that would make life slightly
more difficult for console menu programs, but worst-case, a second
.desktop with an OnlyShowIn could help those menus out if anyone
cares.
- "section" needs semi-manual translation to Categories, though in
theory someone could create a mapping for all the menu sections shown
in /usr/share/doc/menu/menu.txt.gz . Also, for any section whose
corresponding categories don't include the same section names, I'd
suggest adding the verbatim menu section names to Keywords; some menu
systems (such as GNOME's) will use those as additional search terms
for a search-based menu, which may help users used to the menu
sections.
- "command" translates to "Exec", with some editing (e.g. removing
explicit use of "x-terminal-emulator" or similar in favor of
Terminal=true).
- "hints" works similarly to "section": it may inform the selection of
Categories, and some (though not all) of the hints should go into
"Keywords". The sample hints in menu.txt.gz (such as "Big" or
"Expert") shouldn't go into Keywords, but many of the hints used in
practice would make good Keywords.
- "icon" requires substitution of a better icon format; consumers of
.desktop files that can't handle current image formats could always
translate it back, though adding support for current image formats
provides more benefit for comparable effort.

Finally, as a last resort, while option D says you can't ship a menu
file if you also ship a .desktop file, you can still ship a menu file
*instead* of a .desktop file, if you really want to.

Based on the above analysis, I don't see a single instance of menu
metadata that wouldn't translate over to .desktop files.

- Josh Triplett

[Didier 'OdyX' Raboud]

Post by Ian Jackson

Post by Didier 'OdyX' Raboud
Keith's proposal doesn't imply that the trad menu would "be
destroyed" (your words),

It does. There is nothing in Keith's proposal which preserves the
existing trad menu metadata. According to `apt-file search' that is a
database of 2296 menu entries (in wheezy).

Sorry, but this is just _wrong_, and I can't let you continue arguing
that way. All the proposals on the table leave room for the trad-menu to
exist, only that the packages are not required to provide menu entries
themselves anymore.

I think apparmor is a fine example: the maintainers of apparmor do
maintain the apparmor-profiles package which collects apparmor profiles
for packages that don't ship them (or that ship outdated or broken
ones). This gives them an easy way to have an overview of the profiles,
update the outdated ones centrally, etc. Both the apparmor profiles in
the packages and those in the apparmor-profiles package coexist.

The "trad-menu" database will be preserved iff there is enough manpower
to make this happen: either through an automated desktop-to-menu
translation interface, or through a centralisation of that database.

The crux of the issue is IMHO whether it makes sense to continue to put
the burden to maintain this database (with a by-policy larger coverage,
but also technically overcome [icons, translation], etc) on all
packagers through our technical policy. Multiple major desktop
environments simply _ignore_ this database (for a long time), and they
provide the base for a certain majority of our users that make use of
either the trad-menu or the XDG-menu.

Continuing to claim that either fellow developers or to the TC as body
wants the destruction of the 'trad-menu' is IMHO a mis-caracterisation
of these opinions, and feels like a way to twist arms.

Claiming that multiple developers (both during the Policy discussion as
well as here) want to get rid of the "should" obligation imposed on all
application package maintainers to provide "trad-menu" entries seems way
more correct to me.

OdyX

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 28 August 2015 16:06:45 Didier 'OdyX' Raboud wrote:
[snip]

Post by Didier 'OdyX' Raboud
I think apparmor is a fine example: the maintainers of apparmor do
maintain the apparmor-profiles package which collects apparmor profiles
for packages that don't ship them (or that ship outdated or broken
ones). This gives them an easy way to have an overview of the profiles,
update the outdated ones centrally, etc. Both the apparmor profiles in
the packages and those in the apparmor-profiles package coexist.
The "trad-menu" database will be preserved iff there is enough manpower
to make this happen: either through an automated desktop-to-menu
translation interface, or through a centralisation of that database.

FWIW I think this is indeed the way to go if the trad menu wants to keep
itself relevant, specially because...

Post by Didier 'OdyX' Raboud
The crux of the issue is IMHO whether it makes sense to continue to put
the burden to maintain this database (with a by-policy larger coverage,
but also technically overcome [icons, translation], etc) on all
packagers through our technical policy.

...manpower. Indeed if the people interested in keeping the trad menu would
manage it in this way they would be able to even have faster reactions than
going trough each maintainer.

[Lisandro Damián Nicanor Pérez Meyer]

Post by Lisandro Damián Nicanor Pérez Meyer
[snip]

Post by Didier 'OdyX' Raboud
I think apparmor is a fine example: the maintainers of apparmor do
maintain the apparmor-profiles package which collects apparmor profiles
for packages that don't ship them (or that ship outdated or broken
ones). This gives them an easy way to have an overview of the profiles,
update the outdated ones centrally, etc. Both the apparmor profiles in
the packages and those in the apparmor-profiles package coexist.
The "trad-menu" database will be preserved iff there is enough manpower
to make this happen: either through an automated desktop-to-menu
translation interface, or through a centralisation of that database.

FWIW I think this is indeed the way to go if the trad menu wants to keep
itself relevant, specially because...

Post by Didier 'OdyX' Raboud
The crux of the issue is IMHO whether it makes sense to continue to put
the burden to maintain this database (with a by-policy larger coverage,
but also technically overcome [icons, translation], etc) on all
packagers through our technical policy.

...manpower. Indeed if the people interested in keeping the trad menu would
manage it in this way they would be able to even have faster reactions than
going trough each maintainer.

And *maybe* this could be added to the ballot as an alternative suggestion.

[Sune Vuorela]

Post by Ian Jackson
So the real dispute is: should the existing application metadata
database (currently represented by the Debian trad menu files in
(a) continue to be maintained in its existing file format
(b) be translated to a new and more modern file format
(perhaps only for some packages)
(c) be destroyed.
Given that there are people who want to maintain it, I think (c) is
unacceptable.[1]

Unfortunately, the people who wants to maintain it are not the same people who
has to carry the maintenance work (shipping, checking, fixing and managing the
menu files across the packages of the distribution, which is why a) is
unacceptable.
I haven't seen anyone interested in working on tooling[1] to accomplish b)
which leaves just c) as a possibility.

Personally, I'd rather throw away work made by people in the past, than having
people in the current and in the future keep wasting time.

/Sune

[1] Except the desktop2menu tool that I wrote eons ago that creates a good
starting point for creating a menu file, but needs quite some work to be used
on a automatic archive wide scale. I'd also suggest people to start off from
Arch's xdg-menu that has been linked multiple times as a starting ground to
build a menu for the window managers targetting advanced users.

[Matthew Vernon]

Post by Sune Vuorela

Post by Ian Jackson
(c) be destroyed.
Given that there are people who want to maintain it, I think (c) is
unacceptable.[1]

Unfortunately, the people who wants to maintain it are not the same people who
has to carry the maintenance work (shipping, checking, fixing and managing the
menu files across the packages of the distribution, which is why a) is
unacceptable.
I haven't seen anyone interested in working on tooling[1] to accomplish b)
which leaves just c) as a possibility.

That's not much comfort to folk like me who use the trad menu (I'm an
FVWM user) - you're proposing getting rid of something that currently
works, and leaving nothing to replace it with.

Regards,

Matthew

[Sune Vuorela]

Post by Matthew Vernon
That's not much comfort to folk like me who use the trad menu (I'm an
FVWM user) - you're proposing getting rid of something that currently
works, and leaving nothing to replace it with.

https://wiki.archlinux.org/index.php/Xdg-menu

There. something to replace it with.

/Sune

[Sam Hartman]

Hi.
So, after working with Keith yesterday on his option, I think I have a
much better understanding of what the tradeoffs are.
I'd like to present these to the TC as we're about to vote.

I'm ignoring ballot option C (afirm the status quo) in this.

I'm also treating options A and B as the same; the only difference
between them is whether the TC explicitly states that the policy process
reached consensus on the text.


Both Ballot options emphasize the XDG desktop format over the existing
menu format.

Both ballot options remove the requirement that applications provide
menu entries for traditional command-line apps, instead leaving it to
the maintainer.

You could read option AB as leaving both the traditional menu and
.desktop in place for the foreseeable future. The traditional menu would
have entries only for packages where the maintainers feel that's
valuable, and would be used by people who install the text-based menu
(if that's still around) or who run a non-desktop Window manager. In
this option the TC recommends that the menu package automatically
translate .desktop files to menu entries.


Option D goes further. Option D requires that packages drop their
traditional menu entries if they ship .desktop files. (That's done on a
per-application not per-package basis). Under option D you must use
desktop entries and not provide traditional menu entries if you want to
appear on the desktop menus. This means all the common GUI apps will
disappear from the traditional menu until the traditional menu starts
parsing desktop entries.

The belief behind option D is that having two formats for the same rough
type of information is harmful and that the TC has chosen to set policy
that will move us away from that.

Option D is fairly harsh for people using traditional non-desktop window
managers. Packages will probably start pulling traditional menu files,
but we have no one signed up to do the work of getting .desktop files to
work with these. (We could adopt the Arch Linux solution, or we could
adopt something in the menu package, or some combination, but someone
has to do the work.)
Option D doesn't currently have any transition language. We're in
effect saying that the traditional menu and non-desktop window managers
are a marginal enough use case that it's OK if they break unless someone
does the work to keep them running.

Ian is correct that we lose data under option D. We lose the
traditional menu categorization of all the menu entries that get dropped
because those apps have .desktop files. That might come back if we
define ways to encode that in .desktop files, but again we're saying
that if no one does the work it's OK to lose that.

However option D does force the issue. We don't linger along with the
traditional menu and XDG menu having different support for the common
GUI applications. We either get consistency or dropped behavior. That
dropped behavior could in the worst case be the non-desktop window
managers ability to provide useful menus by default. On the other hand
if people put in the work we could get a much more consistent experience
than we do today. And option D does have a nice property of aligning
incentives to do work with those who will benefit from it.

Option D does not provide specific policy text. It does point out what
changes (fairly small) would need to be made to the text from Option AB
(Charles's proposal). My assumption is that the policy editors could
come up with text given the existing proposal and the note in option
option D if we were to decide on option D. Presumably if debian-policy
couldn't even come to consensus on how to adopt text for option D given
a TC decision for option D, someone could NMU policy to implement the TC
decision.

All the options do permit the policy process to make further changes.
So, for example if we approve option D, debian-policy could relatively
quickly come up with text that implements option D, and then if someone
wanted to propose a specific transition plan, they could see if they
could get consensus behind it.

[Nikolaus Rath]

Post by Sam Hartman
Option D goes further. Option D requires that packages drop their
traditional menu entries if they ship .desktop files. (That's done on a
per-application not per-package basis).

That would be a pretty ridiculous situation. So package maintainers
would be free to ship .desktop files as well menu files for their
favorite third menu system, but they *must not* ship menu files for the
traditional debian menu?

Surely there is no need to single out the traditional menu as something
that must not be used. It's sufficient if policy mandates the use of
.desktop files, anything beyond that ought to be entirely up to the
maintainer.


Best,
-Nikolaus

[Sam Hartman]

Post by Sam Hartman
Option D goes further. Option D requires that packages drop
their traditional menu entries if they ship .desktop files.
(That's done on a per-application not per-package basis).

Nikolaus> That would be a pretty ridiculous situation. So package
Nikolaus> maintainers would be free to ship .desktop files as well
Nikolaus> menu files for their favorite third menu system, but they
Nikolaus> *must not* ship menu files for the traditional debian
Nikolaus> menu?

correct.

Nikolaus> Surely there is no need to single out the traditional menu
Nikolaus> as something that must not be used. It's sufficient if
Nikolaus> policy mandates the use of .desktop files, anything beyond
Nikolaus> that ought to be entirely up to the maintainer.

I think the argument in favor of this need is that we're trying to force
a transition of the traditional menu to .desktop as a metadata format.

[Nikolaus Rath]

Post by Sam Hartman

Post by Sam Hartman
Option D goes further. Option D requires that packages drop
their traditional menu entries if they ship .desktop files.
(That's done on a per-application not per-package basis).

Nikolaus> That would be a pretty ridiculous situation. So package
Nikolaus> maintainers would be free to ship .desktop files as well
Nikolaus> menu files for their favorite third menu system, but they
Nikolaus> *must not* ship menu files for the traditional debian
Nikolaus> menu?
correct.
Nikolaus> Surely there is no need to single out the traditional menu
Nikolaus> as something that must not be used. It's sufficient if
Nikolaus> policy mandates the use of .desktop files, anything beyond
Nikolaus> that ought to be entirely up to the maintainer.
I think the argument in favor of this need is that we're trying to force
a transition of the traditional menu to .desktop as a metadata format.

Indeed. The question is why.

A. This comes very close to design work which the CTTE should not be
doing. If there's a conflict between two crappy designs and the CTTE
is asked to rule, then you should pick the less crappy one or decline
to rule, not create an entirely new design.

Having a central design body for Debian may not actually be a bad
idea, but experience (as from this bug) has shown that the CTTE does
not have the necessary manpower.

B. Even if the CTTE were supposed to do design work, or if this clearly
was not design work, it's still not what the CTTE has been asked. You
were asked to override a maintainer.

C. Even if you were supposed to do design work, and had been asked to do
so in this case, who would actually benefit from a forced transition?

- It's certainly not the current users of the traditional menu. In
the short term there worse off (because the menu will become
smaller), and in the long term they can write a converter to matter
if there's a forced transition or not.

- It's probably not the users of .desktop files either (they don't
want all the additional entries).

- It's also not the maintainers (if shipping traditional menu files
is a burden, they can stop doing so even if policy doesn't force
them to remove them).

So who is benefitting?

D. Even if you were supposed to do design work, were asked to do so in
this case, and I forget someone who benefits from this forced
transition, was it really worth delaying a decision for more than a
year and a release cycle? It's not that overruling Bill a year ago
would somehow made a forced transition later on impossible.


I think a lot of things went wrong here.


Best,
-Nikolaus

[Sam Hartman]

Nikolaus> A. This comes very close to design work which the CTTE
Nikolaus> should not be doing. If there's a conflict between two
Nikolaus> crappy designs and the CTTE is asked to rule, then you
Nikolaus> should pick the less crappy one or decline to rule, not
Nikolaus> create an entirely new design.

I agree that we should not pick an entirely new design.
Here though, option D does not pick an entirely new design.
It explains what (if we approve option D) is our objection to option
A/B, explains the small fix and rules on that basis.

If that's too close to design work; if you actually want the TC to only
choose with no comment from the options before it; if you want us not to
raise objections and actually set policy as we are charged with in the
constitution, then you will find absolutely no one willing to serve on
the TC.
Nikolaus> D. Even if you were supposed to do design work, were asked
Nikolaus> to do so in this case, and I forget someone who benefits
Nikolaus> from this forced transition, was it really worth delaying
Nikolaus> a decision for more than a year and a release cycle? It's
Nikolaus> not that overruling Bill a year ago would somehow made a
Nikolaus> forced transition later on impossible.


Fuck no! There's no sanity in the length this process has taken within
the TC.
Things are not working here; we have some real problems, and we are not
responsive at least in my opinion.
On that at least we can agree.

[Ian Jackson]

Post by Sam Hartman
I agree that we should not pick an entirely new design.
Here though, option D does not pick an entirely new design.

Option D does something much much worse. It

- mandates that an new design[1] must be invented

- explicitly says that in the meantime the people must work
to delete the data represented according to the existing design

[1] By which I mean a specification for how to represent the existing
trad menu metadata database in .desktop files.


I think the TC forcing a transition like this, off its own bat, is an
absolutely appalling idea.

Note that neither of the sides in this debate actually want this
outcome. The trad menu's vigorous opponents simply want the trad menu
to go away. The trad menu proponents want to keep it as it is.

There are some people on the .desktop side who find the multiplicity
of formats annoying. For them there is a compromise possible (as I
outlined) involving generating trad menu metatdata in .debs from
.desktop files in sources.

But doing that would not need any significant policy change. If a
maintainer of a package which has a .desktop file wants to arrange to
have their trad menu entry generated from the .desktop file there is
nothing stopping them doing so. (It would need a tiny amount of
technical work on the existing translator.)


At the very least, if the TC is going to force this issue in this way,
there should be:

(a) A grace period for the new design to be worked out before the TC
mandates that existing data should start to be deleted from
Debian.

(b) An explicit statement that when transitioning from trad menu
files to .desktop files, the existing data, currently in the trad
menu files, must be transferred to the .desktop files. (Assuming
that by the end of the grade period the appapriate design and
infrastructure exists.)

(c) A statement about who is to approve the new design, so that it is
not possible for those who want to simply abolish the trad menu
to block (b) by preventing (a).

I think this is an impractical way forward. It effectively requires
the trad menu maintainers to specify an extension to the XDG desktop
file format, and to implement the necessary translation in code which
is owned by people from the XDG side.

But IMO it is the very minimum.

Ian.

[Nikolaus Rath]

Post by Sam Hartman
if you actually want the TC to only
choose with no comment from the options before it; if you want us not to
raise objections and actually set policy as we are charged with in the
constitution,

There is an (important) difference between "set policy" and "create
policy". I object to the latter, not the former.

I am not sure what you mean with "raising objections". Do you mean this
as some sort of formal task? I don't think this is anything that the
constitution charges the ctte with. Or do mean that you just want to
share your personal objections to something as a ctte member? I
certainly don't object to that.

Post by Sam Hartman
then you will find absolutely no one willing to serve on
the TC.

is a rather strong statement. It's easily disproven by finding someone,
and I'm pretty sure that you haven't asked everyone. As a matter of
fact, judging from the different kinds and levels of (publicly visible)
activity of the sitting ctte members, I would expect that at least some
of them would be willing to continue to serve in a ctte that uses its
powers a little less creatively[1].

(Replying to ctte list only, this isn't relevant to the bug at hand
anymore).

Best,
-Nikolaus

[1] No negative connotation implied. I mean "creative" in the sense of
not just picking between the presented options.

[Steve Langasek]

Post by Nikolaus Rath

Post by Sam Hartman
if you actually want the TC to only
choose with no comment from the options before it; if you want us not to
raise objections and actually set policy as we are charged with in the
constitution,

There is an (important) difference between "set policy" and "create
policy". I object to the latter, not the former.

I don't agree that this is an important difference and do not agree with
your interpretation of the constitution.

I also think you are unlikely to persuade the seated members of the TC, all
of whom have been developers for many many years, that their interpretation
of the constitution (whatever that may be for each of them) regarding the
TC's authority to direct policy is wrong, and yours is right.

So I don't think this is a constructive subthread.

[Didier 'OdyX' Raboud]

Post by Nikolaus Rath

Post by Sam Hartman
Nikolaus> Surely there is no need to single out the traditional
Nikolaus> menu as something that must not be used. It's
Nikolaus> sufficient if policy mandates the use of .desktop
Nikolaus> files, anything beyond that ought to be entirely up to
Nikolaus> the maintainer.
I think the argument in favor of this need is that we're trying to
force a transition of the traditional menu to .desktop as a
metadata format.

Indeed. The question is why.
A. This comes very close to design work which the CTTE should not be
doing. If there's a conflict between two crappy designs and the
CTTE is asked to rule, then you should pick the less crappy one or
decline to rule, not create an entirely new design.

I agree that the option D comes very close, and I would have strongly
objected to voting an full-blown patch to debian-policy (which would
really be "detailed design work"). But as currently phrased, I find the
ballot well aligned with §6.1.1: deciding on any matter of technical
policy.

I don't think the TC would work better (or even "well" in absolute
terms) if it constrained itself to only picking from option sets it gets
presented. Sometimes, taking responsibility for the actual technical
policy and for setting good policy is what the TC is charged with by the
constitution.

Cheers,
OdyX

[Ian Jackson]

I had an interesting and helpful conversation with a member of the KDE
team at Debconf. They made an interesting proposal:

* We have machinery that can produce trad menu files from desktop
files.

* It is possible to have extension information in extra fields in a
.desktop file. This could be used to record the trad Debian
category and name metadata currently residing in trad Debian menu
files.

* Where such metadata is accepted by upstream, we could include it in
the primary .desktop file.

* Where such metadata is not accepted by upstream, our tooling could
be arranged to be able to combine XDG information from two .desktop
files, one from upstream and one provided in the Debian package.
This would avoid the need for patching an upstream menu file, which
is unattractive.

* Overall, this would make it possible, therefore, to maintain the
menu information primarily in the more sophisticated .desktop
format, so that source packages with .desktop files would not need
to contain trad menu files too.

The only remaining questions are then :

Q1. Whether it is better to convert from .desktop files to trad
Debian menu files at package build time, or to change the
existing trad menu consumers to be able to convert .desktop
files to the required format ?

There is an easy answer to this: this conversion may involve
image conversion libraries including even perhaps an SVG
renderer, and other conversion software, which is
disproportionately heavyweight for many trad menu consumers.
(Trad menu consumers tend to be non-desktop `lightweight' window
managers.)

Whereas most software that ships a .desktop file will have
fairly extensive build dependencies, and in general adding image
conversion tools to their build dependencies will not be
awkward. This also means the conversion is done once, at
package build, rather than on each end-user system.

Therefore the format specified in the .deb, to be used by trad
menu consumers should continue to be the trad Debian menu file.

Q2. Whether packages (bc, many command line games, ...) which only
want to provide a trad Debian menu entry should do so by
including a .desktop file in the source code, or a trad menu
entry.

I see no need for policy to mandate any particular answer to
this. The maintainer should do what they prefer.

Ian.

[Ian Jackson]

I realise that it was perhaps a tactical error to send both
(a) a message with impassioned rhetoric and (b) a message containing
constructive proposal.

Post by Ian Jackson
I had an interesting and helpful conversation with a member of the KDE
* We have machinery that can produce trad menu files from desktop
files.
* It is possible to have extension information in extra fields in a
.desktop file. This could be used to record the trad Debian
category and name metadata currently residing in trad Debian menu
files.
* Where such metadata is accepted by upstream, we could include it in
the primary .desktop file.
* Where such metadata is not accepted by upstream, our tooling could
be arranged to be able to combine XDG information from two .desktop
files, one from upstream and one provided in the Debian package.
This would avoid the need for patching an upstream menu file, which
is unattractive.
* Overall, this would make it possible, therefore, to maintain the
menu information primarily in the more sophisticated .desktop
format, so that source packages with .desktop files would not need
to contain trad menu files too.
Q1. Whether it is better to convert from .desktop files to trad
Debian menu files at package build time, or to change the
existing trad menu consumers to be able to convert .desktop
files to the required format ?
There is an easy answer to this: this conversion may involve
image conversion libraries including even perhaps an SVG
renderer, and other conversion software, which is
disproportionately heavyweight for many trad menu consumers.
(Trad menu consumers tend to be non-desktop `lightweight' window
managers.)
Whereas most software that ships a .desktop file will have
fairly extensive build dependencies, and in general adding image
conversion tools to their build dependencies will not be
awkward. This also means the conversion is done once, at
package build, rather than on each end-user system.
Therefore the format specified in the .deb, to be used by trad
menu consumers should continue to be the trad Debian menu file.
Q2. Whether packages (bc, many command line games, ...) which only
want to provide a trad Debian menu entry should do so by
including a .desktop file in the source code, or a trad menu
entry.
I see no need for policy to mandate any particular answer to
this. The maintainer should do what they prefer.

I think this would involve:

- defining new field names for .desktop files to contain
the trad menu metadata, as necessary. I think we can safely
call these fields X-Debian-* or X-Debian-Menu-* or something.

- a small amount of work in the already-existing .desktop-to-menu
conversion program

- a policy draft explaining what should come out in the .deb, with
some informative text explaining how to get this effect using only
.desktop files (or perhaps simply giving references to the
appropriate tool documentation)

- policy should probably say that a contributor sending a trad menu
patch for a program with a .desktop file should do so by sending
a .desktop file patch, rather than a trad menu patch.

In the longer term:

- Desktop program maintainers would get occasional patches to add
trad menu metadata to their .desktop files. The tooling would then
do the right thing. This is the only extra human work that those
maintainers would have to do.

- GUI program maintainers have a choice of whether to provide trad
menu entries via this new mechanism or by providing a separate trad
menu file.

- Maintainers of non-GUI programs which don't want to be in the DE
menus can continue to provide menu entries for the trad menu
without needing to interact with the XDG menu system.

- Trad menu consumers do not need to gain any heavyweight runtime
dependencies.

- It is still possible to make the trad menu visible in DEs using the
existing technique. When that is done there are a trad menu entry,
and DE menu entry, for the same program, each categorised and
labelled according to the corresponding menu scheme.

Ian.

[Josselin Mouette]

Post by Ian Jackson
- defining new field names for .desktop files to contain
the trad menu metadata, as necessary. I think we can safely
call these fields X-Debian-* or X-Debian-Menu-* or something.

What is the use case for these fields?

Post by Ian Jackson
- a small amount of work in the already-existing .desktop-to-menu
conversion program

Who cares? We can have much better than that and use the XDG
specification to its full extent:
https://wiki.archlinux.org/index.php/Xdg-menu

Post by Ian Jackson
- policy should probably say that a contributor sending a trad menu
patch for a program with a .desktop file should do so by sending
a .desktop file patch, rather than a trad menu patch.

Good. This way it can be ignored as well.

Post by Ian Jackson
- Desktop program maintainers would get occasional patches to add
trad menu metadata to their .desktop files. The tooling would then
do the right thing. This is the only extra human work that those
maintainers would have to do.

So you complain that dropping entirely the Debian menu (which is the
sensible thing to do) would get rid of a few thousands
mostly-boilerplate files, while we get rid of much more than that in
useless C code every other minor release, but suddenly giving extra work
to all maintainers of packages containing desktop entries is OK?

Maybe some people need to get rid of that mentality where other people
have to do more work to comply with their twisted view of reality.

Post by Ian Jackson
- GUI program maintainers have a choice of whether to provide trad
menu entries via this new mechanism or by providing a separate trad
menu file.

Or to do nothing at all about the trad menu, which is the sensible thing
to do?

Post by Ian Jackson
- Maintainers of non-GUI programs which don't want to be in the DE
menus can continue to provide menu entries for the trad menu
without needing to interact with the XDG menu system.

Or they can provide entries with appropriate
NoDisplay/OnlyShowIn/NotShowIn fields, as described in Charles’ proposed
policy.

Post by Ian Jackson
- Trad menu consumers do not need to gain any heavyweight runtime
dependencies.

Neither do they need to by using xdg_menu.

Post by Ian Jackson
- It is still possible to make the trad menu visible in DEs using the
existing technique.

No, it is not. Maybe in an alternative reality, but in Debian, KDE and
GNOME have both made this impossible, on purpose.

There is no use for the traditional Debian menu. It is deadweight
technology. Any effort invested in it is wasted. Get over it.

[Don Armstrong]

Post by Josselin Mouette
Maybe some people need to get rid of that mentality where other people
have to do more work to comply with their twisted view of reality.

Calling someone else's viewpoint twisted is needlessly inflammatory and
not acceptable when discussing bugs which have been referred to the
CTTE. Please stop.

[Sam Hartman]

Hi.
Your recent post to Ian is inappropriate and not consistent with the
rules of conduct we've established for our communication.
Multiple members of our community have talked to you about this issue.

Please stop.

***@bugs and listmaster copied, although I will not request any
specific action at this time.

- defining new field names for .desktop files to contain the trad
menu metadata, as necessary. I think we can safely call these
fields X-Debian-* or X-Debian-Menu-* or something.

Josselin> What is the use case for these fields?

- a small amount of work in the already-existing .desktop-to-menu
conversion program

Josselin> Who cares? We can have much better than that and use the
Josselin> XDG specification to its full extent:
Josselin> https://wiki.archlinux.org/index.php/Xdg-menu

- policy should probably say that a contributor sending a trad
menu patch for a program with a .desktop file should do so by
sending a .desktop file patch, rather than a trad menu patch.

Josselin> Good. This way it can be ignored as well.

- Desktop program maintainers would get occasional patches to add
trad menu metadata to their .desktop files. The tooling would
then do the right thing. This is the only extra human work that
those maintainers would have to do.

Josselin> So you complain that dropping entirely the Debian menu
Josselin> (which is the sensible thing to do) would get rid of a few
Josselin> thousands mostly-boilerplate files, while we get rid of
Josselin> much more than that in useless C code every other minor
Josselin> release, but suddenly giving extra work to all maintainers
Josselin> of packages containing desktop entries is OK?

Josselin> Maybe some people need to get rid of that mentality where
Josselin> other people have to do more work to comply with their
Josselin> twisted view of reality.

- GUI program maintainers have a choice of whether to provide
trad menu entries via this new mechanism or by providing a
separate trad menu file.

Josselin> Or to do nothing at all about the trad menu, which is the
Josselin> sensible thing to do?

- Maintainers of non-GUI programs which don't want to be in the
DE menus can continue to provide menu entries for the trad menu
without needing to interact with the XDG menu system.

Josselin> Or they can provide entries with appropriate
Josselin> NoDisplay/OnlyShowIn/NotShowIn fields, as described in
Josselin> Charles’ proposed policy.

- Trad menu consumers do not need to gain any heavyweight runtime
dependencies.

Josselin> Neither do they need to by using xdg_menu.

- It is still possible to make the trad menu visible in DEs using
the existing technique.

Josselin> No, it is not. Maybe in an alternative reality, but in
Josselin> Debian, KDE and GNOME have both made this impossible, on
Josselin> purpose.

Josselin> There is no use for the traditional Debian menu. It is
Josselin> deadweight technology. Any effort invested in it is
Josselin> wasted. Get over it.

Josselin> -- Joss

[Keith Packard]

Post by Ian Jackson
* Overall, this would make it possible, therefore, to maintain the
menu information primarily in the more sophisticated .desktop
format, so that source packages with .desktop files would not need
to contain trad menu files too.

Yes, the wording that Sam and I worked out this morning for the final
ballot option advises this kind of solution, where users of the debian
menu system gain access to applications through a combination of menu
and .desktop files.

You can see that draft ballot here:

http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/odyx_draft.txt

Post by Ian Jackson
Q1. Whether it is better to convert from .desktop files to trad
Debian menu files at package build time, or to change the
existing trad menu consumers to be able to convert .desktop
files to the required format ?

I believe that having the debian menu package capable of parsing both
formats will reduce the maintenance burden for packages providing
.desktop files. Someone needs to write a conversion script; adding that
to only the menu package and not all application packages seems like
less work overall.

Post by Ian Jackson
There is an easy answer to this: this conversion may involve
image conversion libraries including even perhaps an SVG
renderer, and other conversion software, which is
disproportionately heavyweight for many trad menu consumers.
(Trad menu consumers tend to be non-desktop `lightweight' window
managers.)

librsvg2-bin and netpbm are what I use for this work; the dependency
list for these is fairly small, and shares almost everything with
requirements to run a fairly basic X desktop. I do not see this as an
excessive burden to run when installing a new package.

Post by Ian Jackson
Q2. Whether packages (bc, many command line games, ...) which only
want to provide a trad Debian menu entry should do so by
including a .desktop file in the source code, or a trad menu
entry.
I see no need for policy to mandate any particular answer to
this. The maintainer should do what they prefer.

The biggest policy change I've proposed is to remove the requirement for
menu files for any package in the archive, and to replace that with a
fairly soft requirement that "desktop applications" have an associated
.desktop file. Otherwise, maintainers are free to do as they like.

Post by Ian Jackson
- defining new field names for .desktop files to contain
the trad menu metadata, as necessary. I think we can safely
call these fields X-Debian-* or X-Debian-Menu-* or something.

I'd like to suggest that all of this additional menu-package specific
information could be delivered with the menu package itself, and not
spread across all of the application packages. As you note, the bulk of
the information loss in translating .desktop to menu files is in the
hierarchy of the debian menu, and not in information tightly tied to the
specific package version, so the information is unlikely to go stale as
things change. By providing some reasonable defaults for Freedesktop
Desktop Menu categories, the need for per-package definitions would be
greatly reduced.

Yes, this seems a bit backwards, but consider the benefits to menu
system users -- it's probably far easier to convince the menu package
maintainers to release a new version that adjusts the location of a new
application within the debian menu system than to get that application
maintainer to package changes which they are reasonably unlikely to be
dependent on.

And, as the hierarchy is defined by the menu system maintainers, it will
likely be more consistent and correct than having the menu
constructed in distributed fashion by a collection of menu system users
and random desktop application maintainers.

[Steve Langasek]

Post by Keith Packard

Post by Ian Jackson
* Overall, this would make it possible, therefore, to maintain the
menu information primarily in the more sophisticated .desktop
format, so that source packages with .desktop files would not need
to contain trad menu files too.

Yes, the wording that Sam and I worked out this morning for the final
ballot option advises this kind of solution, where users of the debian
menu system gain access to applications through a combination of menu
and .desktop files.
http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/odyx_draft.txt

Sorry for missing the IRC meeting this week, I was out with the DebFlu.

I'm happy to see that this discussion has resulted in a draft ballot option
based on your earlier work that seems to have broad support.

741573_menu_systems/keithp_draft.txt includes further guidance regarding the
technical details of how to map between the menu system and .desktop files.
Since this is not on the ballot itself, how do we intend to surface this so
that it can be useful to the Policy process?

[Keith Packard]

Post by Steve Langasek
741573_menu_systems/keithp_draft.txt includes further guidance regarding the
technical details of how to map between the menu system and .desktop files.
Since this is not on the ballot itself, how do we intend to surface this so
that it can be useful to the Policy process?

How about I post that to the bug so it is at least visible?