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

Bug#741573: Comparison of Options AB and D

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

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.

Attachment: pgp80qDLQxYx8.pgp
Description: PGP signature

Reply to: