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

[Sam Hartman <hartmans@debian.org>]

>>>>> "Steve" == Steve Langasek <vorlon@debian.org> writes:

    Steve> On Fri, Aug 28, 2015 at 09:13:33AM -0400, Sam Hartman wrote:
    >> If we adopt Keith's proposal without updating policy 9.6--we
    >> retainIs the SHOULD have menu entries for all command line apps,
    >> but move the metadata format to .desktop, we have a number of
    >> problems.  We have no way to express the category information and
    >> some of the other metadata from the trad menu that's kind of
    >> important for its expanded scope.

    >> So, it's not clear what should happen.

    >> If we revise 9.6 and adopt Keith's proposal then we're basically
    >> adopting the XDG menu's scope, but taking away the place where
    >> the broader information could go.

    >> In effect we leave menu entries that do belong on the trad menu
    >> but do not belong on the XDG menu no where.

    >> Depending on how we do things we may also significantly
    >> complicate the runtime dependencies of light-weight
    >> windowmanagers if we force them to parse .desktop files and do
    >> image conversion.


    >> In effect by adopting Keith's proposal with an update to 9.6,
    >> we're saying that as a matter of technical policy decided by the
    >> TC, there are some menu entries on the trad menu that do not
    >> belong on any menu at all.

    Steve> If this is the message that the ballot option is sending,
    Steve> then I agree that it's concerning.  I'm aware there are some
    Steve> maintainers of desktop environments who view this as the
    Steve> goal; my support for Keith's proposal was predicated on the
    Steve> belief that this would /not/ be the outcome, but instead that
    Steve> we were describing a path forward by which existing menu
    Steve> system entries would be translated into .desktop files and
    Steve> the semantics would be preserved.

    Steve> The XDG .desktop format allows applications to specify that
    Steve> they should or should not be shown in particular environments
    Steve> using the OnlyShowIn/NotShowIn keywords.  I assumed it would
    Steve> be straightforward to declare a new OnlyShowIn value that
    Steve> menu consumers could key on if they wish to show the
    Steve> traditional menu heirarchy, and that this could be
    Steve> implemented without causing any problems for the existing
    Steve> desktop environments.

    Steve> Have I overlooked something that makes this approach
    Steve> untenable?  Should the ballot option be extended to make this
    Steve> a more explicit recommendation?

Since writing that message to Ian, I've thought more about this and
there's been a bit of rewording.  So, I do believe that Keith's draft
more follows what you are talking about.  I think that what Keith came
up with yesterday makes it clear that this is the recommended path
forward.  I think that's especially true if we surface the notes in the
keith_draft.txt as you suggested in another note.

However, we're pushing a fairly harsh transition time table with the
current option D.  At the same time we're recommending the trad menu
package support .desktop files, we are recommending that people pull
trad menu files from packages that also have .desktop files.  That very
quickly gets you into the situation where popular applications like
iceweasel disappear from the older window managers.

Several people have expressed doubts about whether the Menu maintainer
will ever follow our recommendation (and it is only advice) to support
.desktop files.

If no one does the work, itmay be that the trad menu disappears.

I think based on comments you made in the Systemd discussion you may be
OK with that outcome: obligating people who care about the trad menu to
do the work of making it viable for Stretch, although I may be
misremembering who had what positions and your analysis may differ in
this situation.

I think option D is reasonable and will definitely vote it above FD.  I
may or may not rank it first.  If I do it will be exactly because we're
pushing for that transition and trying to move to one metadata format.
If I do not it will be because I think that demanding packages drop menu
files if they keep .desktop files is premature at this time.