Bug#741573: Comparison of Options AB and D

[Ian Jackson]

Sam Hartman writes ("Bug#741573: Comparison of Options AB and D"):
> 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.

Bug#741573: Comparison of Options AB and D

[Didier 'OdyX' Raboud]

Le dimanche, 30 août 2015, 13.01:36 Nikolaus Rath a écrit :
> On Aug 30 2015, Sam Hartman  wrote:
> > 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

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

Bug#741573: Comparison of Options AB and D

[Nikolaus Rath]

On Aug 30 2015, Sam Hartman hartm...@debian.org wrote:
 Nikolaus == Nikolaus Rath nikol...@rath.org writes:

 Nikolaus On Aug 29 2015, Sam Hartman hartm...@debian.org wrote:
  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

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: Comparison of Options AB and D

[Nikolaus Rath]

On Aug 29 2015, Sam Hartman hartm...@debian.org wrote:
 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
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: Comparison of Options AB and D

[Sam Hartman]

 Nikolaus == Nikolaus Rath nikol...@rath.org writes:

Nikolaus On Aug 29 2015, Sam Hartman hartm...@debian.org wrote:
 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.

Bug#741573: Comparison of Options AB and D

[Sam Hartman]

 Nikolaus == Nikolaus Rath nikol...@rath.org writes:

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.

Bug#741573: Comparison of Options AB and D

[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.



pgpJpZ5OqU_Ks.pgp
Description: PGP signature