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

Bug#741573: Comparison of Options AB and D

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

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


Reply to: