[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: