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.
Description: PGP signature