Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Wouter Verhelst]

On Tue, Oct 13, 2015 at 07:56:03AM -0400, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst  writes:
> 
> 
> Wouter> So, I'm with Guillem on this one.
> 
> 
> Wouter> But _forbidding_ maintainers who want to from shipping a
> Wouter> second file, if that somehow makes the experience of menu
> Wouter> users better than what the fdo menu would have given them?
> Wouter> Sorry, but that seems petty and silly.
> 
> OK.
> Then why don't you build consensus behind a patch to do that?
> The TC's decision can be changed by the normal policy process.
> If you can get people to agree with a proposal that permits both
> ..desktop and .menu files then you can replace the TC decision.

Per §4.1.4, Only through a 2:1 supermajority GR. Alternatively, it could
also by replaced by the TC voting a second time on the subject, changing
or clarifying its original decision (an outcome I would favour, but hey,
I'm not a member of the TC).

> For myself, I think that forcing a transition to .desktop will create a
> longer Debian long-term.

[assuming you meant 'better' rather than 'longer']

Yes, I agree with that, and I support that goal. By stating that the
absense of a .desktop file for a graphical program should be considered
a bug, and that the absense of support for the fdo menu in a window
manager should be considered a bug as well, you would have forced such a
transition, and that would/should have been enough.

In contrast, the current TC decision goes one step further, and I think
it goes a bridge too far.

> I believe that the TC's approach provides a useful push for that in
> this situation.  I realize that it is a fairly forceful approach and
> it's not something that Debian does often.

Exactly, and that is one of the major reasons why I think it's a bad
decision.

(for reference: I'm not angry here, just critical and sceptical)

Regards,

Wouter

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> On Tue, Oct 13, 2015 at 07:56:03AM -0400, Sam Hartman wrote:
>> > "Wouter" == Wouter Verhelst  writes:
>> 
>> 
Wouter> So, I'm with Guillem on this one.
>> 
>> 
Wouter> But _forbidding_ maintainers who want to from shipping a
Wouter> second file, if that somehow makes the experience of menu
Wouter> users better than what the fdo menu would have given them?
Wouter> Sorry, but that seems petty and silly.
>> 
>> OK.  Then why don't you build consensus behind a patch to do
>> that?  The TC's decision can be changed by the normal policy
>> process.  If you can get people to agree with a proposal that
>> permits both ..desktop and .menu files then you can replace the
>> TC decision.

Wouter> Per §4.1.4, Only through a 2:1 supermajority
Wouter> GR. Alternatively, it could also by replaced by the TC
Wouter> voting a second time on the subject, changing or clarifying
Wouter> its original decision (an outcome I would favour, but hey,
Wouter> I'm not a member of the TC).

Normally that would be true.

However, the TC included the following language in its decision:

   6. Further modifications to the menu policy are allowed using the
  normal policy modification process.


My understanding is that Keith, Don and I at least intended that
language to allow the policy process to change or replace our decision.
I've run into three people now who did not find that clear.  If the
policy editors asked us to clarify that part of the decision I would
support doing so.  If the policy editors find that language clear enough
that they would feel comfortable merging a proposal that went against
the TC decision if it got enough seconds, etc, then I would find the
current language sufficient.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Wouter Verhelst]

On Tue, Sep 29, 2015 at 11:39:47AM +0200, Didier 'OdyX' Raboud wrote:
> Le mardi, 29 septembre 2015, 02.10:01 Guillem Jover a écrit :
> > Wow, this is such terrible policy… So we have supporters of the XDG
> > format, and supporters of the menu format. Some of those would and
> > have accepted files of their non-preferred format in their packages,
> > some have outright refused them. But now they have to choose between
> > one of them, because they can no longer ship both.
> 
> One of the points of the TC decision is precisely to avoid a "free 
> choice" between the two formats. The first point of that decision is to 
> adopt ba679bff76f5b9152f43d5bc901b9b3aad257479 in the Debian Policy, 
> which contains:
> > Packages shipping applications that comply with minimal requirements
> > described below for integration with desktop environments should
> > register these applications in the desktop menu, (…)
> 
> Applications "should" be registered in the FreeDesktop menu if that 
> makes sense. The second point of the TC decision (which phrasing to be 
> committed in the Debian Policy we're currently discussing) is to forbid 
> applications that do provide XDG menu entries to _also_ provide "trad 
> menu" entries.

So, I'm with Guillem on this one.

Saying that the FreeDesktop menu should be the default and "source"
format, I wholeheartedly support that choice. Making it clear that not
shipping a .menu file is not a bug, and that it is a bug (not
necessarily RC, but still) for a window manager to not look at the fdo
menu? Sure, great policy.

But _forbidding_ maintainers who want to from shipping a second file, if
that somehow makes the experience of menu users better than what the fdo
menu would have given them? Sorry, but that seems petty and silly.

I don't think I'll encounter the issue, seen as none of my packages ship
any menu entry, let alone a .desktop file, today. But yeah, it's
something I think I'll blatantly ignore if/when the time comes.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit :
> But _forbidding_ maintainers who want to from shipping a second file,
> if that somehow makes the experience of menu users better than what
> the fdo menu would have given them? Sorry, but that seems petty and
> silly.

For context, the exact phrasing of the TC decision is "packages 
providing a .desktop file shall not also provide a menu file for the 
same application."

This translates to "this situation constitutes a bug", but doesn't 
specify an explicit patch for the Debian Policy (aka doesn't explicitly 
lay down the severity of the bug). I'd argue that in the absence of a 
new Debian Policy version incorporating the TC decision, such situations 
would be 'serious' bugs. Can we work towards ironing an adequate 
wording? 

> I don't think I'll encounter the issue, seen as none of my packages
> ship any menu entry, let alone a .desktop file, today. But yeah, it's
> something I think I'll blatantly ignore if/when the time comes.

Threatening to "blatantly ignore" the Debian Policy isn't terribly 
helpful.

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:


Wouter> So, I'm with Guillem on this one.


Wouter> But _forbidding_ maintainers who want to from shipping a
Wouter> second file, if that somehow makes the experience of menu
Wouter> users better than what the fdo menu would have given them?
Wouter> Sorry, but that seems petty and silly.

OK.
Then why don't you build consensus behind a patch to do that?
The TC's decision can be changed by the normal policy process.
If you can get people to agree with a proposal that permits both
.desktop and .menu files then you can replace the TC decision.

For myself, I think that forcing a transition to .desktop will create a
longer Debian long-term.  I believe that the TC's approach provides a
useful push for that in this situation.
I realize that it is a fairly forceful approach and it's not something
that Debian does often.
It seems to be a case where the broader community might disagree with
the TC and if that's the case, then I would be happy with that result.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

> "Didier" == Didier 'OdyX' Raboud  writes:

Didier> Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit
Didier> :
>> But _forbidding_ maintainers who want to from shipping a second
>> file, if that somehow makes the experience of menu users better
>> than what the fdo menu would have given them? Sorry, but that
>> seems petty and silly.

Didier> For context, the exact phrasing of the TC decision is
Didier> "packages providing a .desktop file shall not also provide a
Didier> menu file for the same application."

Didier> This translates to "this situation constitutes a bug", but
Didier> doesn't specify an explicit patch for the Debian Policy (aka
Didier> doesn't explicitly lay down the severity of the bug). I'd
Didier> argue that in the absence of a new Debian Policy version
Didier> incorporating the TC decision, such situations would be
Didier> 'serious' bugs. Can we work towards ironing an adequate
Didier> wording?

No, i don't think so at all.
It's quite clear from the TC minutes that serious was not intended, and
 there's no evidence that shall from the TC means the same
 thing as must in the policy.

When I read the message I feel a great frustration because I'm hoping
that we can work with respect.  It sounds like you are trying to build
up an interpretation that was never intended and create a bad
consequence for the status quo to drive resolution.
I do not support that.  I fully realize that it's easy to assume
motivations different than intended.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 13 octobre 2015, 07.52:55 Sam Hartman a écrit :
> >> Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit:
> >> But _forbidding_ maintainers who want to from shipping a second
> >> file, if that somehow makes the experience of menu users better
> >> than what the fdo menu would have given them? Sorry, but that
> >> seems petty and silly.
> 
> Didier> For context, the exact phrasing of the TC decision is
> Didier> "packages providing a .desktop file shall not also provide a
> Didier> menu file for the same application."
> 
> Didier> This translates to "this situation constitutes a bug", but
> Didier> doesn't specify an explicit patch for the Debian Policy (aka
> Didier> doesn't explicitly lay down the severity of the bug). I'd
> Didier> argue that in the absence of a new Debian Policy version
> Didier> incorporating the TC decision, such situations would be
> Didier> 'serious' bugs. Can we work towards ironing an adequate
> Didier> wording?
> 
> No, i don't think so at all.
> It's quite clear from the TC minutes that serious was not intended,
> and there's no evidence that shall from the TC means the same
> thing as must in the policy.

I'm puzzled by your successive positions about this question in this bug 
log, really. But fair enough, I understand you're referring to Keith's 
<86si6udah7@hiro.keithp.com> message:
> we agreed that that this decision would not cause them to be
> classified as RC-buggy for the stretch release.

… although I cannot remember (or find logs for) this precise discussion.

Anyway, I'm hereby retracting my assumption of bug severities to be 
applied on packages shipping applications with both XDG and trad menu 
entries. Let's get back to finding a proper wording implementing the TC 
decision in Policy, please.

OdyX

The role of the TC (was Re: Bug#707851: Debian Menu Systems : Implementation of the TC decision)

[Guillem Jover]

Hi Sam!

I have very low tolerance for what I perceive as unjust. The mere
existence of the TC and any of its invocations implies (to me) an
instance of constitutionally sanctioned injustice and imbalance in
the project, in addition of increased deterioration of the project's
social fabric.

In this case I was not trying to discuss the mandate (sorry for not
making that clear, or for possibly making it seem otherwise), as I
consider any mandate coming from the TC to be final; there is still
the requirement that I pointed out some time ago for a supermajority
in a GR to overturn a TC decision; and given that I do not see myself
ever getting involved with the TC out of my own volition, so it would
go against my principles to try to appeal or discuss officially with
the TC. My mails should be considered more as a protest than anything
else, I guess.

I agree I've probably used a stronger tone than it is usual in me, but
only intended against decisions and institutions, not persons; and I
am aware this might be somewhat self-defeating. In the same way as
refusing to engage in the policy process as a matter of protest is
also self-defeating.

I replied to Josselin, because I felt he was framing me as a menu
supporter, when I come to this from a neutral ground when it comes
to the formats, my complaint lies elsewhere, so I wanted to make my
motives clear.

I do think I understand the reasons for that specific TC mandate. I do
not think the people behind the TC acted in bad faith when deciding on
it. I still think it is wrong, and something that IMO would never had
reached even rough consensus if it had not been forced from above. Also
to me any TC decision even if technically right and sound, is wrong by
definition due to the way it needed to be reached and enacted, so in
this case it feels doubly wrong.

I guess you will perceive this as me trying to have the last word again,
and I do not think this was probably the reply you were looking for, but
it is the one I've got, sorry.

Thanks,
Guillem

Re: Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

I'm happy to engage in a constructive discussion with members of the
project on the advantages and disadvantages here.
The few times you and I have talked in person we've had useful
conversations and I think we learned from each other.

However, I need to be met with respect and a desire for understanding.

If you want to discuss this issue starting from the assumption that both
sides are working to make the best Debian we can; if you are willing to
start by listening rather than shouting; if you are willing to take the
time to understand the tradeoffs that  motivate those with whom you
disagree; then I will meet you.  I will take the time to understand your
position, I will respect your position even when I disagree with it, and
I will try my best to consider and learn from what you have to say.

Today, though, what I hear is that getting the last word in is more
important to you than that sort of connection and growth.
I am disappointed when I think about that.

Sam hartman
Debian Developer

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Guillem Jover]

(Obviously whenever you say you are out of a discussion or will not
 reply anymore there's some compelling reason to do otherwise…)

On Tue, 2015-09-29 at 18:05:02 +0200, Josselin Mouette wrote:
> Guillem Jover  wrote: 
> You seem to be framing this as a XDG vs menu formats. I see it in 
> great
> part as applications showing up on WM/DE or not. The collateral damage
> from the TC decision are applications, WM/DE and its users from either
> format.
> 
> Only if WMs keep on using the Debian menu instead of the XDG menu.
> 
> Err, no, the TC has explicitly made it "impossible" for the two 
> systems
> to coexist, breaking existing support, and forcing maintainers to 
> choose
> one or other ecosystems, w/o any working solution in sight for WM/DE 
> not
> supporting the XDG system. Which has made the situation even worse 
> than
> before, in a very anti social way.
> 
> You might want to package https://wiki.archlinux.org/index.php/Xdg-menu
> which answers exactly the questions you have been asking.

Then you've completely missed the points in my mails. But to try to make
it excruciatingly clear:

 * No one has offered themselves to package, maintain and do any required
   global integration work, any of the times (AFAIK) the above project
   has been mentioned on the mailing lists. The one that came "closer"
   was Charles Plessy on d-d? (#749565)
 * I don't have any problem with the XDG menu spec (I do think it *is*
   fine, but this is besides the point here).
 * I don't see why I should be held responsible to fix the mess that
   others have inflicted onto the project, just for pointing it out.
 * This is about how a very poor mandate puts well meaning maintainers
   in a bind when having to choose between one or the other system, when
   they or their users do not use any of the XDG-enabled environments.
   (If I maintained a package with both menu and XDG entries, while most
   WM/DE do not support XDG entries, I'd probably ignore the TC mandate
   to only ship one entry, as being complete rubbish towards our users).
 * This is about users suddenly missing out on already done work and
   information that was previously there, due to well meaning maintainers
   being forced to remove support for one or the other entries, which by
   my reading is strictly permitted by the TC resolution.
 * This is about very poor transition planning in general, based on
   untested solutions and work no one has even promised to do.
 * This is about the TC yet again failing on §6.3.5.
 * This is about this sad trend in some quarters of the project to try
   to direct it by force instead of by convincing arguments, superior
   solutions, effort or simply working code.

Regards,
Guillem

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 22 septembre 2015, 13.47:31 Charles Plessy a écrit :
> Le Mon, Sep 21, 2015 at 11:27:53AM -0400, Sam Hartman a écrit :
> > Hi.  I've been debating how to respond to the shall vs must thing. 
> > The short answer is that there are reasons why you might prefer
> > shall, but I find that I'd rather say "must is good enough," than
> > try and come up with an articulate presentation of the energy which
> > would conclude by saying that if must still seemed like the right
> > choice go with it.
> > 
> > So,  I'm fine with s/shall/must.
> 
> Thanks Sam,
> 
> the word "shall" appears only once in the Policy (quoted below), so I
> think that avoiding it is consistent with the Policy's style.
> 
>If the package is architecture: any, then
>the shared library compilation and linking flags must have
>-fPIC, or the package shall not build on some of
>the supported architectures
> 
> I still have commit priviledges on the Policy's Git repository on
> Alioth, so if the Policy Editors are busy, I can implement the TC's
> decision.

For what I'm concerned, at least for the "cherry-picking" part of the TC 
decision, please go ahead.

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 29 septembre 2015, 14.34:35 Guillem Jover a écrit :
> Which contains the requirements for the XDG entry, one of those being
> the icon. If the upstream part does not contain a suitable icon, then
> removing the XDG entry and any relevant icon shipped in the debian/
> directory makes the application obviously non-compliant.
> 
> > Applications "should" be registered in the FreeDesktop menu if that
> > makes sense.
> 
> For a menu supporter who packages applications for their own use,
> I'd presume it would be obvious that making them inaccessible from
> their non-XDG compliant environment makes no sense.

Two points here:
* so far, both in the Policy and during the TC discussion, these "menu 
supporters" have been _mostly_ hypothetical;
* these entries would be absent as long as the "menu program" fail to 
properly use the 'XDG menu' entries, that's the point of the TC 
decision.

> > > So we might end up with packages by menu supporters removing
> > > .desktop files, and packages from XDG supporters removing .menu
> > > files. And users of either format caught inbetween.
> > 
> > The TC decision is saying "XDG menu is now the source, it should be
> > read by 'trad menu' programs,
> 
> W/o anyone to implement this in the menu programs, this is just
> wishful thinking, and might leave big chunks of our users with
> inaccessible applications. On either side of the fence.

Yes. That's exactly the point: the work to keep the 'trad menu' relevant 
is to be made by those who care about it.

> > In the light of the TC decision, I would personally consider a
> > package dropping an XDG desktop entry in favor of a menu entry
> > buggy (although there will certainly be cases debatable cases).
> 
> To me this is the equivalent of a package with suitable applications
> for the XDG menu, not currently shipping an XDG entry. So now you
> declare all those insta buggy as well.

Not anymore buggy than with the previous "trad menu" policy (§9.6 in 
3.9.6), for what is worth: it said:
> All packages that provide applications that need not be passed any
> special command line arguments for normal operation should register a
> menu entry for those applications.

Large parts of Debian have been buggy under this text, for a long time.

> > "The TC" is not going to engage in detailed design work (or
> > implementation work, for what is worth), although any of its members
> > could (but I don't see this happening).
> 
> Exactly my point. This is the equivalent of mandating that the Debian
> Future Team should design and implement an FTL engine, where of course
> the TC has not engaged in any design work. This to me fails §6.3.5.

I obviously disagree, but invite you to challenge this decision in 
forums other than the debian-policy list.

Second, the TC has not mandated any work to any particular team: it 
changed the ecosystem in which the 'trad menu' programs evolve. Mind 
you, program ecosystems evolve all the time; 'trad menu's was relying on 
the Debian Policy mandating entries for all applications "that need not 
be passed any special command line arguments", the TC decision drops 
that requirement.

--
OdyX

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

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Charles Plessy]

Le Tue, Sep 29, 2015 at 03:25:25PM +0200, Didier 'OdyX' Raboud a écrit :
> 
> I noticed you committed this typo of mine to the git repository, sorry 
> for that:
> 
> Le jeudi, 17 septembre 2015, 15.25:54 Didier 'OdyX' Raboud a écrit :
> > +  Applications that are registred in the desktop menu shall
> ---^

Corrected, thanks.

>From this and the "colon" patch I conclude that I definitely need to go to bed.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Guillem Jover]

On Tue, 2015-09-29 at 11:39:47 +0200, Didier 'OdyX' Raboud wrote:
> Le mardi, 29 septembre 2015, 02.10:01 Guillem Jover a écrit :
> > Wow, this is such terrible policy… So we have supporters of the XDG
> > format, and supporters of the menu format. Some of those would and
> > have accepted files of their non-preferred format in their packages,
> > some have outright refused them. But now they have to choose between
> > one of them, because they can no longer ship both.
> 
> One of the points of the TC decision is precisely to avoid a "free 
> choice" between the two formats. The first point of that decision is to 
> adopt ba679bff76f5b9152f43d5bc901b9b3aad257479 in the Debian Policy, 
> which contains:
> > Packages shipping applications that comply with minimal requirements
> > described below for integration with desktop environments should
> > register these applications in the desktop menu, (…)

Which contains the requirements for the XDG entry, one of those being
the icon. If the upstream part does not contain a suitable icon, then
removing the XDG entry and any relevant icon shipped in the debian/
directory makes the application obviously non-compliant.

> Applications "should" be registered in the FreeDesktop menu if that 
> makes sense.

For a menu supporter who packages applications for their own use,
I'd presume it would be obvious that making them inaccessible from
their non-XDG compliant environment makes no sense.

> The second point of the TC decision (which phrasing to be 
> committed in the Debian Policy we're currently discussing) is to forbid 
> applications that do provide XDG menu entries to _also_ provide "trad 
> menu" entries.

Sure, and that's still terrible policy, and self-conflicting at best with
the rest of the decision.

(Whatever happened to letting technical solutions win or loose for their
own merits, and from work or lack thereof from supporters, instead of by
letting a big broken hammer fall in slow-motion on them…)

> > So we might end up with packages by menu supporters removing .desktop
> > files, and packages from XDG supporters removing .menu files. And
> > users of either format caught inbetween.
> 
> The TC decision is saying "XDG menu is now the source, it should be read 
> by 'trad menu' programs,

W/o anyone to implement this in the menu programs, this is just wishful
thinking, and might leave big chunks of our users with inaccessible
applications. On either side of the fence.

So it feels like "let's make a mess, and hope someone else cleans it up
for us when they get sufficiently annoyed".

> and _can_ be completed for the range of 
> applications that don't make sense in the XDG menu, but do make sense in 
> the 'trad menu'".

> Like it or not, this is decided, and we're "only" 
> discussing how this should take form in the Debian Policy.

I don't have a horse in this race except for wanting Debian to be sound,
I just think the decision is very poor. I'm also not trying to discuss
how this should end up in policy. As I've mentioned several times now,
as long as the policy process is overrun by the TC, I've got no
motivation to get properly involved in it. Clearly someone else has
decided to do the job.

> In the light of the TC decision, I would personally consider a package 
> dropping an XDG desktop entry in favor of a menu entry buggy (although 
> there will certainly be cases debatable cases).

To me this is the equivalent of a package with suitable applications
for the XDG menu, not currently shipping an XDG entry. So now you
declare all those insta buggy as well.

> > Also is the TC going to implement the changes in the "menu programs"
> > to support the XDG format? Because I don't see the ruling to be very
> > motivating for the menu supporters.
> 
> "The TC" is not going to engage in detailed design work (or 
> implementation work, for what is worth), although any of its members 
> could (but I don't see this happening).

Exactly my point. This is the equivalent of mandating that the Debian
Future Team should design and implement an FTL engine, where of course
the TC has not engaged in any design work. This to me fails §6.3.5.

Regards,
Guillem

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Hi Charles,

I noticed you committed this typo of mine to the git repository, sorry 
for that:

Le jeudi, 17 septembre 2015, 15.25:54 Didier 'OdyX' Raboud a écrit :
> +  Applications that are registred in the desktop menu shall
---^

Cheers,
OdyX

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

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Le mardi, 29 septembre 2015, 02.10:01 Guillem Jover a écrit :
> Wow, this is such terrible policy… So we have supporters of the XDG
> format, and supporters of the menu format. Some of those would and
> have accepted files of their non-preferred format in their packages,
> some have outright refused them. But now they have to choose between
> one of them, because they can no longer ship both.

One of the points of the TC decision is precisely to avoid a "free 
choice" between the two formats. The first point of that decision is to 
adopt ba679bff76f5b9152f43d5bc901b9b3aad257479 in the Debian Policy, 
which contains:
> Packages shipping applications that comply with minimal requirements
> described below for integration with desktop environments should
> register these applications in the desktop menu, (…)

Applications "should" be registered in the FreeDesktop menu if that 
makes sense. The second point of the TC decision (which phrasing to be 
committed in the Debian Policy we're currently discussing) is to forbid 
applications that do provide XDG menu entries to _also_ provide "trad 
menu" entries.

> So we might end up with packages by menu supporters removing .desktop
> files, and packages from XDG supporters removing .menu files. And
> users of either format caught inbetween.

The TC decision is saying "XDG menu is now the source, it should be read 
by 'trad menu' programs, and _can_ be completed for the range of 
applications that don't make sense in the XDG menu, but do make sense in 
the 'trad menu'". Like it or not, this is decided, and we're "only" 
discussing how this should take form in the Debian Policy.

In the light of the TC decision, I would personally consider a package 
dropping an XDG desktop entry in favor of a menu entry buggy (although 
there will certainly be cases debatable cases).

> Also is the TC going to implement the changes in the "menu programs"
> to support the XDG format? Because I don't see the ruling to be very
> motivating for the menu supporters.

"The TC" is not going to engage in detailed design work (or 
implementation work, for what is worth), although any of its members 
could (but I don't see this happening).

Cheers,
OdyX

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Charles Plessy]

Le Tue, Sep 29, 2015 at 09:24:20AM +0200, Didier 'OdyX' Raboud a écrit :
> 
> For what I'm concerned, at least for the "cherry-picking" part of the TC 
> decision, please go ahead.

Commited and pushed!

I attached a consolidated patch that summarises the changes.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan
diff --git a/debian/changelog b/debian/changelog
index d48eac8..d3ddfe7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -31,6 +31,14 @@ debian-policy (3.9.7.0) unstable; urgency=low
 Seconded: Bill Allombert 
 Seconded: Charles Plessy 
 Closes: #106073
+  * Policy, as per decision of the Technical Committee:
+[9.6] Document the FreeDesktop menu entries.  Packages providing a .desktop
+file must not also provide a .menu file for the same application.
+[9.7] Document the FreeDesktop media type declarations.
+See: 
+Wording: Charles Plessy 
+Wording: Didier 'OdyX' Raboud 
+Closes: #707851
 
  -- Bill Allombert   Fri, 08 May 2015 15:10:02 +0200
 
diff --git a/policy.sgml b/policy.sgml
index 404dc73..40f9f3f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8130,81 +8130,189 @@ Reloading description configuration...done.
 	Menus
 
 	
-	  The Debian menu package provides a standard
-	  interface between packages providing applications and
-	  menu programs (either X window managers or
-	  text-based menu programs such as pdmenu).
+	  Packages shipping applications that comply with minimal requirements
+	  described below for integration with desktop environments should
+	  register these applications in the desktop menu, following the
+	  FreeDesktop standard, using text files called
+	  desktop entries.  Their format is described in the
+	  Desktop Entry Specification at
+	  http://standards.freedesktop.org/desktop-entry-spec/latest/;>
+	  and complementary information can be found in the
+	  Desktop Menu Specification at
+	  http://standards.freedesktop.org/menu-spec/latest/;>.
 	
 
 	
-	  All packages that provide applications that need not be
-	  passed any special command line arguments for normal
-	  operation should register a menu entry for those
-	  applications, so that users of the menu package
-	  will automatically get menu entries in their window
-	  managers, as well in shells like pdmenu.
+	  The desktop entry files are installed by the packages in the
+	  directory /usr/share/applications and the FreeDesktop
+	  menus are refreshed using dpkg triggers.  It is therefore
+	  not necessary to depend on packages providing FreeDesktop menu
+	  systems.
 	
 
 	
-  Menu entries should follow the current menu policy.
+	  Entries displayed in the FreeDesktop menu should conform to the
+	  following minima for relevance and visual integration.
+
+	  
+	
+	  Unless hidden by default, the desktop entry must point to a PNG
+	  or SVG icon with a transparent background, providing at least
+	  the  size, and preferably up to 6464.  The icon
+	  should be neutral enough to integrate well with the default icon
+	  themes.  It is encouraged to ship the icon in the default
+	  hicolor icon theme directories, or to use an existing
+	  icon from the hicolor theme.
+	
+
+	
+	  If the menu entry is not useful in the general case as a
+	  standalone application, the desktop entry should set the
+	  NoDisplay key to true, so that it can be
+	  configured to be displayed only by those who need it.
+	
+
+	
+	  In doubt, the package maintainer should coordinate with the
+	  maintainers of menu implementations through the
+	  debian-desktop mailing list in order to avoid problems
+	  with categories or bad interactions with other icons.  Especially
+	  for packages which are part of installation tasks, the contents
+	  of the NotShowIn/OnlyShowIn keys should be
+	  validated by the maintainers of the relevant environments.
+	
+	  
 	
 
 	
-	  The menu policy can be found in the menu-policy
-	  files in the debian-policy package.
-	  It is also available from the Debian web mirrors at
-  http://www.debian.org/doc/packaging-manuals/menu-policy/;>.
+	  Since the FreeDesktop menu is a cross-distribution standard, the
+	  desktop entries written for Debian should be forwarded upstream,
+	  where they will benefit to other users and are more likely to
+	  receive extra contributions such as translations.
 	
 
-	
-	  Please also refer to the Debian Menu System
-	  documentation that comes with the menu
-	  package for information about how to register your
-	  applications.
+
+	  Applications that are not registered in the desktop menu can optionally provide a
+	  Debian menu file, following the Debian menu policy,
+	  which can be found in the menu-policy files in the
+	  debian-policy 

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Guillem Jover]

On Tue, 2015-09-29 at 15:13:28 +0200, Didier 'OdyX' Raboud wrote:
> Le mardi, 29 septembre 2015, 14.34:35 Guillem Jover a écrit :
> > W/o anyone to implement this in the menu programs, this is just
> > wishful thinking, and might leave big chunks of our users with
> > inaccessible applications. On either side of the fence.
> 
> Yes. That's exactly the point: the work to keep the 'trad menu' relevant 
> is to be made by those who care about it.

You seem to be framing this as a XDG vs menu formats. I see it in great
part as applications showing up on WM/DE or not. The collateral damage
from the TC decision are applications, WM/DE and its users from either
format.

> > > "The TC" is not going to engage in detailed design work (or
> > > implementation work, for what is worth), although any of its members
> > > could (but I don't see this happening).
> > 
> > Exactly my point. This is the equivalent of mandating that the Debian
> > Future Team should design and implement an FTL engine, where of course
> > the TC has not engaged in any design work. This to me fails §6.3.5.
> 
> I obviously disagree, but invite you to challenge this decision in 
> forums other than the debian-policy list.

I find that such kind of formal bureaucratic move would be a waste of
time, which if I wanted to waste, I'd rather do trying to get the TC
disbanded as a toxic and polarizing institution for the project. But
I don't think the project is prepared for this, just yet.

> Second, the TC has not mandated any work to any particular team: it 
> changed the ecosystem in which the 'trad menu' programs evolve. Mind 
> you, program ecosystems evolve all the time; 'trad menu's was relying on 
> the Debian Policy mandating entries for all applications "that need not 
> be passed any special command line arguments", the TC decision drops 
> that requirement.

Err, no, the TC has explicitly made it "impossible" for the two systems
to coexist, breaking existing support, and forcing maintainers to choose
one or other ecosystems, w/o any working solution in sight for WM/DE not
supporting the XDG system. Which has made the situation even worse than
before, in a very anti social way.

And I don't see how point 3 of the TC resolution can be read otherwise,
but whatever.

Anyway this discussion in itself is a waste of time, so I'm getting out…

Regards,
Guillem

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Josselin Mouette]

Guillem Jover  wrote: 
You seem to be framing this as a XDG vs menu formats. I see it in great
part as applications showing up on WM/DE or not. The collateral damage
from the TC decision are applications, WM/DE and its users from either
format.

Only if WMs keep on using the Debian menu instead of the XDG menu.

Err, no, the TC has explicitly made it "impossible" for the two systems
to coexist, breaking existing support, and forcing maintainers to choose
one or other ecosystems, w/o any working solution in sight for WM/DE not
supporting the XDG system. Which has made the situation even worse than
before, in a very anti social way.

You might want to package https://wiki.archlinux.org/index.php/Xdg-menu
which answers exactly the questions you have been asking.

-- 
Joss

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Guillem Jover]

On Thu, 2015-09-17 at 15:25:54 +0200, Didier 'OdyX' Raboud wrote:
>  
> -   Packages can, to be compatible with Debian additions to some window
> -   managers that do not support the FreeDesktop standard, also provide a
> +   Applications that are not registered in the desktop menu can 
> optionally provide a
> Debian menu file, following the Debian menu policy,
> which can be found in the menu-policy files in the
> debian-policy package.  It is also available from the Debian
> web mirrors at  id="http://www.debian.org/doc/packaging-manuals/menu-policy/;>.
>   
> +
> +
> +  Applications that are registred in the desktop menu shall not also
> +  provide a Debian menu file for the same application.
> +
>

Wow, this is such terrible policy… So we have supporters of the XDG
format, and supporters of the menu format. Some of those would and
have accepted files of their non-preferred format in their packages,
some have outright refused them. But now they have to choose between
one of them, because they can no longer ship both. So we might end up
with packages by menu supporters removing .desktop files, and packages
from XDG supporters removing .menu files. And users of either format
caught inbetween.

Also is the TC going to implement the changes in the "menu programs"
to support the XDG format? Because I don't see the ruling to be very
motivating for the menu supporters.

Regards,
Guillem

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> Le Mon, Sep 21, 2015 at 11:27:53AM -0400, Sam Hartman a
Charles> écrit :
>> Hi.  I've been debating how to respond to the shall vs must
>> thing.  The short answer is that there are reasons why you might
>> prefer shall, but I find that I'd rather say "must is good
>> enough," than try and come up with an articulate presentation of
>> the energy which would conclude by saying that if must still
>> seemed like the right choice go with it.
>> 
>> So, I'm fine with s/shall/must.

Charles> Thanks Sam,

Charles> the word "shall" appears only once in the Policy (quoted
Charles> below), so I think that avoiding it is consistent with the
Charles> Policy's style.

Nod, I think it was clear from your first message that this was your
argument.
I agree it's a valid position someone could take.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Charles Plessy]

Le Mon, Sep 21, 2015 at 11:27:53AM -0400, Sam Hartman a écrit :
> Hi.  I've been debating how to respond to the shall vs must thing.  The
> short answer is that there are reasons why you might prefer shall, but I
> find that I'd rather say "must is good enough," than try and come up
> with an articulate presentation of the energy which would conclude by
> saying that if must still seemed like the right choice go with it.
> 
> So,  I'm fine with s/shall/must.

Thanks Sam,

the word "shall" appears only once in the Policy (quoted below), so I think
that avoiding it is consistent with the Policy's style.

   If the package is architecture: any, then
   the shared library compilation and linking flags must have
   -fPIC, or the package shall not build on some of
   the supported architectures

I still have commit priviledges on the Policy's Git repository on Alioth, so if
the Policy Editors are busy, I can implement the TC's decision.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Sam Hartman]

Hi.  I've been debating how to respond to the shall vs must thing.  The
short answer is that there are reasons why you might prefer shall, but I
find that I'd rather say "must is good enough," than try and come up
with an articulate presentation of the energy which would conclude by
saying that if must still seemed like the right choice go with it.

So,  I'm fine with s/shall/must.

Sent mostly to give Charles some support so things don't stall.

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Charles Plessy]

Le Thu, Sep 17, 2015 at 03:25:54PM +0200, Didier 'OdyX' Raboud a écrit :
> > 
> I'm hereby proposing the following diff for point 2, as a discussion
> starter:
> 
> diff --git a/policy.sgml b/policy.sgml
> index ee1e9f4..83e4057 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8192,14 +8192,18 @@ Reloading description configuration...done.
>   
>  
>  
> -   Packages can, to be compatible with Debian additions to some window
> -   managers that do not support the FreeDesktop standard, also provide a
> +   Applications that are not registered in the desktop menu can 
> optionally provide a
> Debian menu file, following the Debian menu policy,
> which can be found in the menu-policy files in the
> debian-policy package.  It is also available from the Debian
> web mirrors at  id="http://www.debian.org/doc/packaging-manuals/menu-policy/;>.
>   
> +
> +
> +  Applications that are registred in the desktop menu shall not also
> +  provide a Debian menu file for the same application.
> +
>
>  
>

Hi Didier,

thanks a lot to you and the TC for bringing this issue to a conclusion.

I think that your patch is good.  Minor nitpick: the Policy does not use the
word "shall" much - I guess it is to help non-native speakers like me.  If I
understand well, it means "must" ?  In that case, I propose to replace it by
"must".

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#707851: Debian Menu Systems : Implementation of the TC decision

[Didier 'OdyX' Raboud]

Control: severity -1 important

Hi all,

As you have certainly seen on debian-devel-announce [0], the Technical
Committee has ruled on the question of Debian Menu Systems, and the
technical decision should now find a form within the Debian Policy.

First, the commit designed in the aforementionned decision [1] must be
cherry-picked in the Debian Policy repository by whoever has the rights
to do so, ideally by one of the Policy editors.

Second, we should discuss an appropriate phrasing for putting the
points 2 and 3 of the TC decision into the Debian Policy:

>2. In addition to those changes, the Technical Committee resolves
>   that packages providing a .desktop file shall not also provide a
>   menu file for the same application.
> 
>3. We further resolve that "menu programs" should not depend on the
>   Debian Menu System and should instead rely on .desktop file
>   contents for constructing a list of applications to present to
>   the user.

I'm hereby proposing the following diff for point 2, as a discussion
starter:

diff --git a/policy.sgml b/policy.sgml
index ee1e9f4..83e4057 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8192,14 +8192,18 @@ Reloading description configuration...done.

 
 
- Packages can, to be compatible with Debian additions to some window
- managers that do not support the FreeDesktop standard, also provide a
+ Applications that are not registered in the desktop menu can 
optionally provide a
  Debian menu file, following the Debian menu policy,
  which can be found in the menu-policy files in the
  debian-policy package.  It is also available from the Debian
  web mirrors at http://www.debian.org/doc/packaging-manuals/menu-policy/;>.

+
+
+  Applications that are registred in the desktop menu shall not also
+  provide a Debian menu file for the same application.
+
   
 
   

Cheers,
OdyX

[0] 
https://lists.debian.org/msgid-search/20150904033414.gd3...@qor.donarmstring.com
[1] 
https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

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