Le dimanche, 30 août 2015, 22.01:27 Keith Packard a écrit : > 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.
> 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].
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>,
+ (…)
> 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
signature.asc
Description: This is a digitally signed message part.
