Debian Bug report logs - #741573
On menu systems.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: submit@bugs.debian.org

Subject: On menu systems.

Date: Fri, 14 Mar 2014 09:19:33 +0900

Package: tech-ctte
Severity: normal

Dear technical comittee,

I am asking for your arbitration on an unresolvable conflict on the subject of
Desktop menu systems, between a broad number of developers including on one
hand maintainers of the Debian packages for the GNOME and KDE desktop systems
and the mime-support package (myself), and on the other hand Bill Alombert on
his quality of Policy Editor (DPL delegate).

Over almost one year of work and discussion, including a call for comments on
the debian-devel mailing list, we have shaped a modification to the Debian
Policy that 1) incorporates the description of the FreeDesktop menu system and
its use in Debian for listing program in desktop menus and associating them
with media types, and 2) softens the wording on the Debian Menu system to
reflect that in Jessie it will be neither displayed nor installed by default on
standard Debian installations.

The proposal reached consensus through the Policy Changes process, was seconded
by me, Lisandro Damián Nicanor Pérez Meyer, Cyril Brulebois and Russ Allbery,
who is also Policy Editor and assessed that the consensus was obtained.
Apparently without coordination with the other Policy Editors, Bill then
canceled the change and has been avoiding any concrete discussion the change.

You can find the proposal at the following URL.

    http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=ba679bff76f5b9152f43d5bc901b9b3aad257479;hp=f6997b3ba793c9a9e463cca9f7e7b138add8b788

The whole discussion is at https://bugs.debian.org/707851.

I will not describe Bill's behaviour in further details unless you ask me to do
so, but the end result is that me and others are stongly dissatisfied by his
obstructive attitude and unilateral veto, to the point that we do not think
that discussion is possible and we need a decision from a third party.  I am
asking you to overrule Bill and let me or the Policy Editors upload an updated
version of the Policy containing our changes.

I will inform Bill and the debian-policy mailing list in the thread for #707851
once I have a bug number for this appeal.

Please let me know if there is further information you need.

Cheers, and many thanks for your work.

-- 
Charles Plessy
Maintainer of the 'mime-support' package
Tsurumi, Kanagawa, Japan

Message #10 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: On menu systems.

Date: Thu, 13 Mar 2014 17:29:08 -0700

Charles Plessy <plessy@debian.org> writes:

> I am asking for your arbitration on an unresolvable conflict on the
> subject of Desktop menu systems, between a broad number of developers
> including on one hand maintainers of the Debian packages for the GNOME
> and KDE desktop systems and the mime-support package (myself), and on
> the other hand Bill Alombert on his quality of Policy Editor (DPL
> delegate).

For the information of the other Technical Committee members and other
interested folks, I want to give advance notice that, as a party in this
dispute, I will be recusing myself from voting on the topic.

To the extent that I have time to contribute to the discussion, please
read those contributions as coming from one of the interested parties
and one of the Policy editors rather than as a Technical Committee member.

I realize that we previously discussed escalated issues from Policy and
decided that those of us (both Manoj and I at the time) who were both
Policy Editors and Technical Committee members should not recuse
themselves, but I think I have a more significant conflict here than with
a typical escalated Policy issue.  This issue is, in part, an internal
team conflict between Bill and myself, so I don't think it's appropriate
for me to vote.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #15 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org, Charles Plessy <plessy@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: On menu systems.

Date: Thu, 13 Mar 2014 20:35:59 -0600

[Message part 1 (text/plain, inline)]

Russ Allbery <rra@debian.org> writes:

> This issue is, in part, an internal team conflict between Bill and
> myself, so I don't think it's appropriate for me to vote.

Thanks for being up-front about this, Russ.

Please do contribute to the discussion.

Bdale

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: On menu systems.

Date: 25 Mar 2014 17:40:27 +0000

Charles Plessy <plessy@debian.org> writes:

> Over almost one year of work and discussion, including a call for comments on
> the debian-devel mailing list, we have shaped a modification to the Debian
> Policy that 1) incorporates the description of the FreeDesktop menu system and
> its use in Debian for listing program in desktop menus and associating them
> with media types, and 2) softens the wording on the Debian Menu system to
> reflect that in Jessie it will be neither displayed nor installed by default on
> standard Debian installations.

I'm rather non-plussed by the proposal to devalue the Debian Menu
system. I use fvwm, and while for frequently-used apps I don't use the
menu (instead launching them from particular keys), the Debian menu is
how I both launch apps I use less frequently, and explore what I've
got installed. Its comprehensive coverage means that if I'm not quite
sure what application I want, I can have a bit of a browse and try
things out. Any proposal that reduces the coverage of the Debian Menu
seems a bad idea for me...

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Message #25 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: On menu systems.

Date: Tue, 25 Mar 2014 13:52:09 -0400

[Message part 1 (text/plain, inline)]

On Tue, Mar 25, 2014 at 05:40:27PM +0000, Matthew Vernon wrote:
> I'm rather non-plussed by the proposal to devalue the Debian Menu
> system. I use fvwm, and while for frequently-used apps I don't use the
> menu (instead launching them from particular keys), the Debian menu is
> how I both launch apps I use less frequently, and explore what I've
> got installed. Its comprehensive coverage means that if I'm not quite
> sure what application I want, I can have a bit of a browse and try
> things out. Any proposal that reduces the coverage of the Debian Menu
> seems a bad idea for me...

Since DE/WMs are coming up, let me put on my Fluxbox (as the Debian
maintainer, not as upstream) hat.


Fluxbox is one of the larger consumers of the menu system. There have been
murmers for the last fre years in the fluxbox dev rooms about eventually
adding XDG Menu stuff into fluxbox, to replace the home-brew menu files
in ~/.fluxbox

A statement that the menu system in Debian is out-of-date and other systems
(which, frankly, work better) are the prefered system to use would likely be
the kick that we need to exorcise menu from Fluxbox (likely upstream as
well, but I'm not speaking to that right now).


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Matthew Vernon <matthew@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: On menu systems.

Date: Tue, 25 Mar 2014 11:11:39 -0700

Matthew Vernon <matthew@debian.org> writes:

> I'm rather non-plussed by the proposal to devalue the Debian Menu
> system. I use fvwm, and while for frequently-used apps I don't use the
> menu (instead launching them from particular keys), the Debian menu is
> how I both launch apps I use less frequently, and explore what I've got
> installed. Its comprehensive coverage means that if I'm not quite sure
> what application I want, I can have a bit of a browse and try things
> out. Any proposal that reduces the coverage of the Debian Menu seems a
> bad idea for me...

(Speaking with my Policy hat on, per my previous message to this bug.)

There are two different issues here, which unfortunately are currently
linked.

The first issue is the file format and, more generally, the data model.
While there are some features in the Debian menu file format that are not
present in desktop files, I don't believe any of them are particularly
vital.  There are more features in desktop files that are not currently
representable in the Debian menu file format.  And, more importantly, the
desktop file format is a general standard, the files are often shipped by
upstream, and the format is being actively developed and improved by other
people whose work we can take advantage of.

While there are some transition headaches, I think the file format and
data model of desktop files is generally better, and that aligning with it
will reduce our maintenance and integration burden going forward.  I think
we should be working towards a long-term goal of adopting desktop files
and phasing out menu files.  (Note that, by this, I mean the files in
/usr/share/menu that are shipped by individual packages, not the files in
/etc/menu-methods that provide integration with window managers.)

The second issue is integration of the menu into Debian packages.  Right
now, the Debian native menu system has better integration, particularly
into the non-DE window managers.  (Putting aside for the moment that the
DEs largely disable the Debian native menu because it mostly duplicates
the menu generated from desktop files and they believe it to be less
useful.)  If we abandon menu files right now and switch entirely to
desktop files, we lose several integrations that we currently have.

I think the ideal long-term outcome would be for someone to do the work
that Charles did for the MIME registry and either convert from desktop
files to menu files for the benefit of our existing integrations or redo
those integrations to support desktop files, whichever makes the most
sense in any particular case.  That would let us switch to a more
broadly-used and widely-developed format and data model without losing any
features.

The problem at the moment is that no one has stepped forward to do that
work, and the desktop environment packaging teams are voting with their
feet towards using the desktop files instead of the Debian menu system for
a variety of reasons, mostly related to the additional features and better
integration in desktop environments offered by desktop files.  So, right
now, if you want complete integration of your package into all of the menu
systems, you have to provide configuration for both systems.

This is obviously rather annoying for packagers, and it would be nice to
avoid the duplicate work.

For most, but definitely not all, of our users, providing the desktop file
is more important than providing the menu configuration.  If we do
nothing, the likely outcome is that more and more packagers who are using,
e.g., GNOME or KDE will install or provide desktop files, find that their
program appears in the menus, assume they're done, and move on, and the
menu quality in other integrations like fvwm will keep declining.  I
believe this has been happening for the past couple of years, although
that's based on a gut feeling and I've not tried to acquire actual data.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #35 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: On menu systems.

Date: Tue, 25 Mar 2014 19:52:45 +0100

[Message part 1 (text/plain, inline)]

Russ Allbery <rra@debian.org> (2014-03-25):
> For most, but definitely not all, of our users, providing the desktop
> file is more important than providing the menu configuration.  If we
> do nothing, the likely outcome is that more and more packagers who are
> using, e.g., GNOME or KDE will install or provide desktop files, find
> that their program appears in the menus, assume they're done, and move
> on, and the menu quality in other integrations like fvwm will keep
> declining.  I believe this has been happening for the past couple of
> years, although that's based on a gut feeling and I've not tried to
> acquire actual data.

The following won't reflect packages possibly moving from menu to fdo,
but should give some idea (the {main/,} bit is there because stuff was
moved around on the archive side). Also, as you know, the archive keeps
growing.


Packages with menu files:
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h '^usr/share/menu/' $i/{main/,}Contents-amd64.gz 2>/dev/null | awk '{print $2}' | sort -u | wc -l; done
  squeeze: 2363
  wheezy: 2290
  jessie: 2306

=> stable

Menu files;
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h '^usr/share/menu/' $i/{main/,}Contents-amd64.gz 2>/dev/null | sort -u | wc -l; done
  squeeze: 2363
  wheezy: 2290
  jessie: 2306

=> stable


Packages with desktop files:
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h '^usr/share/applications/.*\.desktop\b' $i/{main/,}Contents-amd64.gz 2>/dev/null | awk '{print $2}' | sort -u | wc -l; done
  squeeze: 1976
  wheezy: 2186
  jessie: 2324

=> +17% between squeeze and jessie.

Desktop files:
  $ for i in squeeze wheezy jessie; do printf "$i: ";  zgrep -h '^usr/share/applications/.*\.desktop\b' $i/{main/,}Contents-amd64.gz 2>/dev/null | sort -u | wc -l; done
  squeeze: 2592
  wheezy: 2814
  jessie: 3010

=> +16% between squeeze and jessie.


Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

Subject: Bug#741573: Two menu systems

Date: Tue, 8 Apr 2014 18:30:26 +0100

I have a very different take on this to Russ.

We currently have two menu systems.  I'm going to call them the "trad"
and "desktop" menus.


They have the following very important differences (some of these are
matters of opinion, but I will take what appear to me to be the
opinions of their respective maintainers):

Scope: The trad menu is supposed to contain pretty much everything
that can be executed, including command-line programs (to be run via a
terminal).  For example, bc has a trad menu entry.  Conversely, the
desktop menu is supposed to contain only a subset of programs that are
considered useful for users to find and invoke via a menu.

Organisation/categorisation: Both the trad and desktop menus have had
effort put in by their respective maintainers into organising the
menus into subheadings etc.  However, these categorisations are
different.

Consumers: The trad menu is already consumable by a very wide range of
window managers etc.; the desktop menu is consumed primarily by
desktop environments.

Technology: The two systems have different file formats. While the
semantics of the information presented overlap, there are substantial
differences in the capabilities of the two systems.  The trad menu
makes lower demands on menu entry consumers, and conversely imposes
more restrictions on menu entry providers.  The desktop menu gives
more flexibility for menu entry providers, and consequently is harder
to support as a menu consumer.

Both menu systems have sufficient supporters and users that they are
independently viable projects.  Some people will say that the trad
menu is dead and no-one uses it, but that's clearly not true.
Consider the package
   http://qa.debian.org/popcon.php?package=menu-xdg
which provides a view of the trad menu in desktop system which
supports the desktop (XDG) menus.

It therefore seems to me that the correct approach is to continue to
support and develop both these systems.



Given the historical conflict between the maintainers of the two
systems, we need to lay down clear boundaries.  In the spirit of
do-ocracy, decisions about each menu system should be made by its
respective sets of maintainers.

So each menu system's maintainers should:

 * Determine the technical and social policy for their own
   menu system (subject to the usual review);

 * Decide for their own system whether a particular package
   should have an entry in that menu.  (Initially, such decisions
   would be made by the package maintainer of course, guided by
   policy);

 * Decide how that menu entries should be categorised;

 * Decide if and when to make changes to their file format and
   infrastructure, including developing appropriate transition plans
   etc.

I.e., each menu system's maintainers and proponents should be enabled
to do the work they want to do, to make the menu system that they
prefer be as good as it can be.  No-one should block their work or
nonconsensually deprecate it.


My conclusion is:

 * Debian policy should contain two sections on menus.

 * Section on the trad menu should say what it currently says.
   In particular, it should continue to say that pretty much all
   relevant packages should provide trad menu entries.

   Failure to provide a trad menu entry (when the trad menu
   maintainers would like such a menu entry to exist) is a bug.

 * Section on the desktop menu should say whatever the desktop people
   think is appropriate, including descriptions of file formats, when
   and how to categorise entries, etc.

   As above, failure to provide a desktop menu entry when the program
   is covered by the guidelines would be a bug.

As a consequence, many maintainers will need to provide both files in
their output binary packages.  This is by no means an unreasonable
burden on individual package maintainers.  No-one is suggesting that
failing to provide a menu entry would be an RC bug.

We should treat this the same way we treat lack of a manpage: there
are plenty of packages in Debian with no manpages.  But we expect that
if someone who is keen on manpages writes a manpage, the package
maintainer will take the patch.  (And the risk with manpages, that
they become out of date, doesn't really apply for menu entries.)

A maintainer of a package which wants to be in both menus might choose
to put two separate menu entry source files in their source package.
I think this is probably the best approach: the amount of metadata
duplication involved is minimal, and having two source files avoids
any possibility of irreconcilable conflict between the opinions of the
two menu systems.

But if a maintainer wants (for example) to generate a trad menu file
from an desktop file, then that's fine.  BUT this is ONLY PROVIDED
that the generated trad menu file is properly confirming to the trad
menu specification and has the descriptive text, categorisation, etc.,
preferred by the trad menu maintainers.


Thanks,
Ian.

Message #45 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@vuorela.dk>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Tue, 08 Apr 2014 22:23:50 +0200

Hi

I think there is a couple of facts that aren't fully accurate. I'll try to 
mention them here. I'll try to keep opinions out of this mail.

On Tuesday 08 April 2014 18:30:26 Ian Jackson wrote:
> Consumers: The trad menu is already consumable by a very wide range of
> window managers etc.; the desktop menu is consumed primarily by
> desktop environments.

Note that a very wide range of window managers neither supports the trad. menu 
nor the desktop menu, but has a series of scripts to modify one or the other 
into their native format. In Debian, most of these window managers only has 
the scripts for the trad. menu, while the rest of the internet have the 
scripts that uses the desktop menu.

> Both menu systems have sufficient supporters and users that they are
> independently viable projects.  Some people will say that the trad
> menu is dead and no-one uses it, but that's clearly not true.
> Consider the package
>    http://qa.debian.org/popcon.php?package=menu-xdg
> which provides a view of the trad menu in desktop system which
> supports the desktop (XDG) menus.

Note that the KDE Desktop task until earlier this year did install menu-xdg, 
and still does it, and the Gnome and XFCE desktops tasks also installed it at 
one point, so these numbers aren't fully usable.

> But if a maintainer wants (for example) to generate a trad menu file
> from an desktop file, then that's fine.  BUT this is ONLY PROVIDED
> that the generated trad menu file is properly confirming to the trad
> menu specification and has the descriptive text, categorisation, etc.,
> preferred by the trad menu maintainers.

As the author of desktop2menu, I can tell that in some cases it is possible to 
generate it, but in the general case it is not possible to use autogeneration. 
It is - like the help2man script - good to create a template. 

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Message #50 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: Sune Vuorela <sune@vuorela.dk>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Tue, 8 Apr 2014 16:54:50 -0400

[Message part 1 (text/plain, inline)]

On Tue, Apr 08, 2014 at 10:23:50PM +0200, Sune Vuorela wrote:
> Note that a very wide range of window managers neither supports the trad. menu 
> nor the desktop menu, but has a series of scripts to modify one or the other 
> into their native format. In Debian, most of these window managers only has 
> the scripts for the trad. menu, while the rest of the internet have the 
> scripts that uses the desktop menu.

That's right. Like I mentioned earlier, with my Fluxbox maintainer hat
on, getting rid of traditional menu system for desktop sounds great;
might even lead to fixing this upstream, rather then doing it in the
Debian packaging.

Everyone else seems to be using xdg-menu these days anyway; taking a
guess (I've not checked this out), GNOME, KDE and Xfce likely all use
XDG menus, so I think Fluxbox is the largest consumer.

(Sune, Xfce people, correct me if I'm wrong :) )

I'm happy to change it to use XDG menus, or accept patches doing so. 

> Note that the KDE Desktop task until earlier this year did install menu-xdg, 
> and still does it, and the Gnome and XFCE desktops tasks also installed it at 
> one point, so these numbers aren't fully usable.
> 
> > But if a maintainer wants (for example) to generate a trad menu file
> > from an desktop file, then that's fine.  BUT this is ONLY PROVIDED
> > that the generated trad menu file is properly confirming to the trad
> > menu specification and has the descriptive text, categorisation, etc.,
> > preferred by the trad menu maintainers.
> 
> As the author of desktop2menu, I can tell that in some cases it is possible to 
> generate it, but in the general case it is not possible to use autogeneration. 
> It is - like the help2man script - good to create a template. 
> 
> /Sune

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 741573@bugs.debian.org (full text, mbox, reply):

From: "Didier 'OdyX' Raboud" <odyx@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 09 Apr 2014 08:33:30 +0200

Le mardi, 8 avril 2014, 18.30:26 Ian Jackson a écrit :
> Technology: The two systems have different file formats. While the
> semantics of the information presented overlap, there are substantial
> differences in the capabilities of the two systems. 

The 'trad' menu file or the 'desktop' xdg file are only the starting 
point of their technical differences; one other technical difference 
that matters is the support for icon formats.

From the 'desktop' icon theme spec:
> The supported image file formats are PNG, XPM and SVG. PNG is the
> recommended bitmap format, and SVG is for vectorized icons. XPM is
> supported due to backwards compability reasons, and it is not
> recommended that new themes use XPM files. Support for SVGs is
> optional.

In practice, we have icons up to 1024^2 in PNG and only vlc and 
libreoffice (on my system) ship .xpm icons in the xdg repositories.

From the 'trad' Debian Menu System:
> * The icons should be in xpm format.
> * The icons may not be larger than 32x32 pixels, although smaller
>   sizes are ok.
> (…)
> You can provide both 16x16 and 32x32 pixels icons using the variables
> icon16x16 and icon32x32 so that the user can configure menu to use one 
> or the other.

This doesn't say what non-xpm icon formats are supported and in 
practice, the icon path also has to be specified completely; one can't 
provide more than two (fixed) icon resolutions either.

Enforcing the use of the antique XPM format in a limited resolutions set 
is one of the pains of the 'trad' menu system IMHO. In practice, in 
order to add an xpm icon to one of my packages [0] which already shipped 
a .desktop file, an SVG icon and built various sizes' pngs at build-time 
using rsvg-convert [1], I had to add an imagemagick build-dependency and 
convert it out of the 32^2 png icon as I didn't find a software to 
convert the svg directly to xpm.

Frankly, I don't mind shipping a .menu file in debian/ as that's picked 
by dh_installmenu, but it would be vastly better if the 'trad' menu 
could at least adopt the freedesktop icon theme specification. The fact 
that this is a Debian specificity that saw no upload in two years, I'd 
be surprised to see much further developement happen though.

Cheers,
OdyX

[0] src:colobot if that matters
[1] To be fair, I proposed that code to upstream.

Message #60 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: "Didier 'OdyX' Raboud" <odyx@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 9 Apr 2014 12:21:28 +0100

Didier 'OdyX' Raboud writes ("Bug#741573: Two menu systems"):
> The 'trad' menu file or the 'desktop' xdg file are only the starting 
> point of their technical differences; one other technical difference 
> that matters is the support for icon formats.

You have missed my key point about differences of goals between the
two menu systems.  The trad menu explicitly has the goal of providing
a menu item for every invokable thing; whereas the desktop menu
maintainers want it to provide only entries for a much smaller subset
of programs.

This means that we need two systems.

Now in principle you might argue that the "comprehensive" menu should
also be provided via xdg desktop files because they are supposedly
technically superior.

However, this technical superiority is disputed by the maintainers of
the software for handling the trad menu.  Under the circumstances I
think it is not appropriate to try to enforce an "upgrade".

> >From the 'trad' Debian Menu System:
> > * The icons should be in xpm format.
...
> This doesn't say what non-xpm icon formats are supported

Yes, it clearly does.  "The icons should be in xpm format".  I.e. no
non-xpm formats are supported.  The set of supported non-xpm formats
is empty.

> and in practice, the icon path also has to be specified completely;
> one can't provide more than two (fixed) icon resolutions either.

This is not, however, a disbenefit of the trad system.  It does reduce
the capability of the system as a whole, and impose more constraints
on the providers of menu entries.  But the other side of that is that
it is easier to consume menu entries.  It's a tradeoff.

> Enforcing the use of the antique XPM format

I don't think there is anything wrong with the xpm format for small
fixed-size icons.  "Antique" is here a pejorative word for "well
supported by a range of mature and reliable software".

> in a limited resolutions set
> is one of the pains of the 'trad' menu system IMHO.

The limited set of resolutions is another tradeoff that makes it
easier for a wm to consume menu entries.

>  In practice, in 
> order to add an xpm icon to one of my packages [0] which already shipped 
> a .desktop file, an SVG icon and built various sizes' pngs at build-time 
> using rsvg-convert [1], I had to add an imagemagick build-dependency and 
> convert it out of the 32^2 png icon as I didn't find a software to 
> convert the svg directly to xpm.

The alternative would be to force menu entry consumers to add a
similar dependency.  It is IMO better to have a build-dependency than
an install-time dependency.

If you think imagemagick is too heavyweight, perhaps you would prefer
pbmplus.

Thanks,
Ian.

Message #65 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 09 Apr 2014 15:13:40 +0200

[Message part 1 (text/plain, inline)]

Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit :
> You have missed my key point about differences of goals between the
> two menu systems.  The trad menu explicitly has the goal of providing
> a menu item for every invokable thing; whereas the desktop menu
> maintainers want it to provide only entries for a much smaller subset
> of programs.
> 
> This means that we need two systems.

I don't think I missed the point; I was bringing a orthogonal one. I 
understand you think the 'trad' menu is a useful metadata collection on top of 
$PATH for 'every invokable thing'; I happen to disagree.

> > Enforcing the use of the antique XPM format
> 
> I don't think there is anything wrong with the xpm format for small
> fixed-size icons.  "Antique" is here a pejorative word for "well
> supported by a range of mature and reliable software".

For the record, I intended "antique" to litterally mean "antique": "Old, (...) 
out of date." [0]. You are putting words in my mouth by assuming I meant it in 
a pejorative way.

That said, while "old" is factual, "out of date" is arguably subjective. I 
think I can agree with there being nothing wrong with the xpm format for small 
fixed-size icons, but I don't think "small fixed-size icons" is the experience 
we should aim to offer in the future: screens and resolutions are still 
getting bigger and a 32^2 icons will look smaller and smaller (or uglier and 
uglier) over time. We do have more modern formats to use right now; we're not 
discussing adopting a brand new image format, but PNG or SVG!

Cheers,
OdyX

[0] https://en.wiktionary.org/wiki/antique

[signature.asc (application/pgp-signature, inline)]

Message #70 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Matthias Klumpp <mak@debian.org>

To: "Didier 'OdyX' Raboud" <odyx@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 9 Apr 2014 15:50:25 +0200

2014-04-09 15:13 GMT+02:00 Didier 'OdyX' Raboud <odyx@debian.org>:
> Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit :
>> You have missed my key point about differences of goals between the
>> two menu systems.  The trad menu explicitly has the goal of providing
>> a menu item for every invokable thing; whereas the desktop menu
>> maintainers want it to provide only entries for a much smaller subset
>> of programs.
>>
>> This means that we need two systems.
>
> I don't think I missed the point; I was bringing a orthogonal one. I
> understand you think the 'trad' menu is a useful metadata collection on top of
> $PATH for 'every invokable thing'; I happen to disagree.
Regarding metadata, this is something other sources (e.g. DEP-11) can
provide in a much better and less redundant way. What would be
interesting to know is: Why would I want to launch non-GUI
applications from a menu? Usually people working with these launch
them from a Terminal.
Can you provide a usecase for that, other than "it has always been this way"?

>> > Enforcing the use of the antique XPM format
>>
>> I don't think there is anything wrong with the xpm format for small
>> fixed-size icons.  "Antique" is here a pejorative word for "well
>> supported by a range of mature and reliable software".
>
> For the record, I intended "antique" to litterally mean "antique": "Old, (...)
> out of date." [0]. You are putting words in my mouth by assuming I meant it in
> a pejorative way.
>
> That said, while "old" is factual, "out of date" is arguably subjective. I
> think I can agree with there being nothing wrong with the xpm format for small
> fixed-size icons, but I don't think "small fixed-size icons" is the experience
> we should aim to offer in the future: screens and resolutions are still
> getting bigger and a 32^2 icons will look smaller and smaller (or uglier and
> uglier) over time. We do have more modern formats to use right now; we're not
> discussing adopting a brand new image format, but PNG or SVG!
Also think about HIDPI-screens in particular, where these small icons
don't make sense at all (in fact, they are so small that you often
can't even tell what they display).
Cheers,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Message #75 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Didier 'OdyX' Raboud <odyx@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 9 Apr 2014 15:00:44 +0100

Didier 'OdyX' Raboud writes ("Bug#741573: Two menu systems"):
> Le mercredi, 9 avril 2014, 12.21:28 Ian Jackson a écrit :
> > This means that we need two systems.
> 
> I don't think I missed the point; I was bringing a orthogonal one. I
> understand you think the 'trad' menu is a useful metadata collection
> on top of $PATH for 'every invokable thing'; I happen to disagree.

Right.  I understand that some people don't think the comprehensive
menu is useful.  However, there are a lot of things in Debian that
some people think aren't useful.  The usual principle is that if
someone thinks something useful and wants to do the work to provide
it, they should be able to do so.

That applies, obviously, to individual packages.  But it applies to a
lot of other cross-package things too: examples include manpages,
cross compiling, hardening build flags, and indeed the desktop-style
menus.  I'm sure people can think of others.

Our general approach is that it is a bug if a package fails to provide
one of these - but that there is no reason not to upload or upgrade
(or migrate to testing) a package for such a bug.  Instead, the
workflow is this: the maintainer can choose to work on the bug if they
wish; if they don't, then someone who is interested in the feature can
do the work and submit the result for inclusion in the package.


> We do have more modern formats to use right now; we're not
> discussing adopting a brand new image format, but PNG or SVG!

As I have explained, there are tradeoffs here.  To support a more
sophisticated format, all the menu consumers need to be updated.

But the real question is: who should be making this decision ?

We need two menu systems because of disagreements about the content of
the menus.  I think that decisions about the technological future of
the trad menu should be made by the people who are working on, and
continue to promote, the comprehensive menu.


> > I don't think there is anything wrong with the xpm format for small
> > fixed-size icons.  "Antique" is here a pejorative word for "well
> > supported by a range of mature and reliable software".
> 
> For the record, I intended "antique" to litterally mean "antique":
> "Old, (...)  out of date." [0]. You are putting words in my mouth by
> assuming I meant it in a pejorative way.

Are you saying you _didn't_ mean it pejoratively ?  I'm sorry, but I
find that implausible.  Particularly as you now clarify that you mean
"out of date" which is also pejorative.

If you didn't mean it pejoratively, I think you need to seriously
reconsider your communication style, because your comment that xpm was
"antique" looked critical to me.  I can't see why you would use that
word if you intended a neutral meaning.  And indeed if the meaning was
neutral, the word performs no useful function in your sentence, since
the sentence is arguing against the use of xpm.

Perhaps we are just disagreeing about the meaning of the word
"pejorative".  To my mind a phrase describing software is pejorative
if it unjustifiably combines a factual meaning (e.g. "has been around
a long time") with a critical implication (e.g. "... and this a bad
thing").

So, entertainingly, the word "pejorative" is itself pejorative.  By
describing your statement as "pejorative" I was implicitly criticising
it, just as by describing xpm as "antique" you were criticising it.

Let me put my criticism of your use of "antique" another way: your
imply that having been around for a long time is a bad thing.
However, I disagree.  There are significant advantages to use of a
longstanding file format.

These advantages are more important in the widely-consumed trad menu
than they would be in the less-widely-consumed but more sophisticated
desktop menu.

Ian.

Message #80 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Matthias Klumpp <mak@debian.org>, 741573@bugs.debian.org, Matthew Vernon <matthew@debian.org>

Cc: "Didier 'OdyX' Raboud" <odyx@debian.org>

Subject: Re: Bug#741573: On menu systems. [and 1 more messages]

Date: Wed, 9 Apr 2014 15:04:02 +0100

Matthias Klumpp writes ("Bug#741573: Two menu systems"):
> Regarding metadata, this is something other sources (e.g. DEP-11) can
> provide in a much better and less redundant way. What would be
> interesting to know is: Why would I want to launch non-GUI
> applications from a menu? Usually people working with these launch
> them from a Terminal.
> Can you provide a usecase for that, other than "it has always been this way"?

Matthew Vernon has already answered this question earlier in this
thread:

Matthew Vernon writes ("Bug#741573: On menu systems."):
> I'm rather non-plussed by the proposal to devalue the Debian Menu
> system. I use fvwm, and while for frequently-used apps I don't use the
> menu (instead launching them from particular keys), the Debian menu is
> how I both launch apps I use less frequently, and explore what I've
> got installed. Its comprehensive coverage means that if I'm not quite
> sure what application I want, I can have a bit of a browse and try
> things out. Any proposal that reduces the coverage of the Debian Menu
> seems a bad idea for me...

Ian.

Message #85 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Matthias Klumpp <mak@debian.org>, 741573@bugs.debian.org

Cc: "Didier 'OdyX' Raboud" <odyx@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 9 Apr 2014 15:04:36 +0100

Matthias Klumpp writes ("Bug#741573: Two menu systems"):
> Also think about HIDPI-screens in particular, where these small icons
> don't make sense at all (in fact, they are so small that you often
> can't even tell what they display).

In situations like this, presumably the icons would need to be scaled.
Whether the menu consumer (window manager) supports doing this is a
quality of implementation issue for that menu consumer.

If you find that a menu consumer doesn't support that, then I'm sure
patches would be welcome.

Ian.

Message #90 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 09 Apr 2014 09:04:04 -0700 (PDT)

[Message part 1 (text/plain, inline)]

On Wednesday 09 April 2014 15:04:36 Ian Jackson wrote:
> Matthias Klumpp writes ("Bug#741573: Two menu systems"):
> > Also think about HIDPI-screens in particular, where these small icons
> > don't make sense at all (in fact, they are so small that you often
> > can't even tell what they display).
> 
> In situations like this, presumably the icons would need to be scaled.
> Whether the menu consumer (window manager) supports doing this is a
> quality of implementation issue for that menu consumer.

And why not the opposite? Require bigger sizes and let the menu consumer 
downscale it?


-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #95 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 09 Apr 2014 18:27:55 +0200

Le mercredi, 9 avril 2014, 15.00:44 Ian Jackson a écrit :
> Right.  I understand that some people don't think the comprehensive
> menu is useful.  However, there are a lot of things in Debian that
> some people think aren't useful.  The usual principle is that if
> someone thinks something useful and wants to do the work to provide
> it, they should be able to do so.

I think this is allowed by the patch pointed by Charles, which adds the 
following paragraph to the policy:

> Packages can, to be compatible with Debian additions to some window
> managers that do not support the FreeDesktop standard, also provide a
> <em>Debian menu</em> file, following the <em>Debian menu policy</em>,
> which can be found in the <tt>menu-policy</tt> files in the
> <tt>debian-policy</tt> package.  It is also available from the Debian
> web mirrors at <tt><url name="/doc/packaging-manuals/menu-policy/"
> id="http://www.debian.org/doc/packaging-manuals/menu-policy/"></tt>.

As I read it, the complete patch is essentially the addition of a 'desktop' 
menu 'should' and a s/should/can/g for the 'trad' menu. That patch got its 
three seconds within the usual Policy process but got (fully) reverted by 
Bill.

Are you suggesting the 'trad' menu should stay at 'should'? Do you agree with 
the promotion of the 'desktop' menu to a 'should'?

> (snip a lot of vocabulary nitpicking)

Let's rephrase succintly then: xpm is an old format; there is a trend showing 
that more and more packages ship .desktop files [0] along with svg and/or png 
icons; it would therefore ease maintainers' adoption of 'trad' menu entries if 
the 'trad' menu would just support these new icon formats in addition or in 
replacement of xpm. That's all I wanted to say.

> There are significant advantages to use of a longstanding file format.
> 
> These advantages are more important in the widely-consumed trad menu
> than they would be in the less-widely-consumed but more sophisticated
> desktop menu.

Your assertions about how widely the two menu systems are consumed seem quite 
bold to me and are at least not backed by Cyril numbers in 741573#35 [0].

Cheers,
OdyX

[0] <20140325185237.GE15553@mraw.org>

Message #100 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Didier 'OdyX' Raboud <odyx@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 09 Apr 2014 13:27:46 -0400

>>>>> "Didier" == Didier 'OdyX' Raboud <odyx@debian.org> writes:

    Didier> I think this is allowed by the patch pointed by Charles,
    Didier> which adds the following paragraph to the policy:

    >> Packages can, to be compatible with Debian additions to some
    >> window managers that do not support the FreeDesktop standard,
    >> also provide a <em>Debian menu</em> file, following the
    >> <em>Debian menu policy</em>, which can be found in the
    >> <tt>menu-policy</tt> files in the <tt>debian-policy</tt> package.
    >> It is also available from the Debian web mirrors at <tt><url
    >> name="/doc/packaging-manuals/menu-policy/"
    >> id="http://www.debian.org/doc/packaging-manuals/menu-policy/"></tt>.

Hi.
Thanks for bringing this issue back to the question that was brought to
the TC.

The discussion so far on this bug has focused on discussing what the
right  menu policy is for Debian.

That, however was not the question that was brought to the TC.

As I understand it, the claim was made that a consensus was reached
through the normal process and that one of the maintainers reverted
changes consistent with that consensus because he questioned whether the
consensus call was correct.

I appreciate that deciding menu policy is within the scope of the TC,
and if the TC finds that there is no consensus, it seems entirely
reasonable for the TC to choose to create such a policy.

However, I'm disappointed when I see TC members diving into the
technical details in this instance.  I hope that the TC would respect
the broader decision making within the project, would support the idea
that if a broader decision can be reached, that iit is valuable to
support that.  If there is a broader consensus based on the discussion
within the policy process I'd hope that TC members would be very
reluctant to re-open that even if the decision reached is not the one
they are most in favor of.

There's a significant cost to being involved in a consensus process that
doesn't reach a conclusion.  I'd hope that the TC members would choose
to respect the time and energy of all those who participated rather than
taking everything on themselves.

So, I'd like to request the TC to first consider whether a consensus was
reached in the process and if so whether there's a compelling reason not
to respect that consensus.  If no consensus was reached or the TC finds
it has a compelling  interest not to respect that consensus, then
focusing on the technical details of the policy seems reasonable.
In my opinion, not respecting the project as a whole enough to make a
determination about consensus does significant harm.

Respectfully,

Sam Hartman

Message #105 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Didier 'OdyX' Raboud <odyx@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 9 Apr 2014 23:34:51 +0100

Didier 'OdyX' Raboud writes ("Bug#741573: Two menu systems"):
> Le mercredi, 9 avril 2014, 15.00:44 Ian Jackson a écrit :
> > Right.  I understand that some people don't think the comprehensive
> > menu is useful.  However, there are a lot of things in Debian that
> > some people think aren't useful.  The usual principle is that if
> > someone thinks something useful and wants to do the work to provide
> > it, they should be able to do so.
> 
> I think this is allowed by the patch pointed by Charles, which adds the 
> following paragraph to the policy:
...
> As I read it, the complete patch is essentially the addition of a 'desktop' 
> menu 'should' and a s/should/can/g for the 'trad' menu. That patch got its 
> three seconds within the usual Policy process but got (fully) reverted by 
> Bill.

It is the demotion of the traditional menu from "should" to "can"
which is controversial.  For the reasons I have already explained, I
do not agree with that.

> > There are significant advantages to use of a longstanding file format.
> > 
> > These advantages are more important in the widely-consumed trad menu
> > than they would be in the less-widely-consumed but more sophisticated
> > desktop menu.
> 
> Your assertions about how widely the two menu systems are consumed
> seem quite bold to me and are at least not backed by Cyril numbers
> in 741573#35 [0].

By "widely consumed" I meant that a wide range of different window
managers are capable of displaying the traditional menu.

But it seems that you interpreted my comment as referring to the use
of the trad menu by end users, and I want to respond to that.  Of
course we don't know how often end users actually click on the trad
menu and use it to find and launch programs.  So I won't assert that
it's "widely used".  Equally, assertions that it's not used by end
users are unjustified.  We don't know how widely it's used.

We do have testimonial evidence from individual people saying they
find it useful, and we have the evidence from the people working on
providing the trad menu that they think it's a good thing to keep on
using.  For me, that is enough to say that we should continue to allow
those people who care about it to work on it.

Of course Cyril's message #35 that you refer to doesn't talk about the
consumption of the trad menu at all.  It talks only about the _supply_
of menu entries.

Some maintainers want to declare the trad menu obsolete and abolish
it, and have been reluctant to include trad menu entries or have
removed them, contrary to policy and indeed thus sabotaging the work
of the trad menu maintainers.  It is gratifying to see that this
doesn't seem to be widespread, looking at Cyril's statistics.

Ian.

Message #110 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: Didier 'OdyX' Raboud <odyx@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Wed, 9 Apr 2014 23:46:11 +0100

Sam Hartman writes ("Bug#741573: Two menu systems"):
> So, I'd like to request the TC to first consider whether a consensus was
> reached in the process and if so whether there's a compelling reason not
> to respect that consensus.  If no consensus was reached or the TC finds
> it has a compelling  interest not to respect that consensus, then
> focusing on the technical details of the policy seems reasonable.
> In my opinion, not respecting the project as a whole enough to make a
> determination about consensus does significant harm.

This is hardly the first time that a matter has come to the TC after a
dispute has escalated to acts (on one or both sides) whose legitimacy
is disputed.  I doubt it will be the last.  Our approach has always
been to look at the underlying dispute and try to resolve it.

So, no.  The TC will not make decisions about the content of policy on
the basis of an adjudications about the policy process.  We will rule
on the underlying question(s), on the merits.

(In my view, the menu question should have been referred to the TC
much sooner.)

The legitimacy of the actions of the policy maintainers is a matter
for the policy team as a whole, and in extremis for the DPL (given
that the policy team are DPL delegates).  However I would strongly
encourage everyone not to dwell on the alleged wrongs of the
disputants.  Such discussions are unpleasant and almost always
unproductive.

Ian.

Message #115 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 09:22:47 +0900

Le Wed, Apr 09, 2014 at 11:34:51PM +0100, Ian Jackson a écrit :
> 
> It is the demotion of the traditional menu from "should" to "can"
> which is controversial.  For the reasons I have already explained, I
> do not agree with that.

Hi Ian,

yes, it is that part that is controversial, and I would appreciate if the TC
would focus on it, since this was the original topic of #707851, entitled
“soften the wording recommending menu files”. 

The underlying question is: who should spend the time writing these files and
keeping them up to date ?

In the case of missing manual pages, the policy (§ 12.1) does not require the
package maintainer to write one.

As a general principle, I think that this is the right way.  Pacakge
maintainers are volunteers, and we should be careful to avoid loading them with
extra work.  

Therefore, I think that the “should” of §9.6, paragraph 2 should be relaxed.

Needless to say, patches carrying Debian menu entries should be accepted.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #120 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 09:39:00 +0200

[Message part 1 (text/plain, inline)]

Le mercredi 09 avril 2014 à 15:04 +0100, Ian Jackson a écrit : 
> Matthias Klumpp writes ("Bug#741573: Two menu systems"):
> > Also think about HIDPI-screens in particular, where these small icons
> > don't make sense at all (in fact, they are so small that you often
> > can't even tell what they display).
> 
> In situations like this, presumably the icons would need to be scaled.

Faced with such nonsensical words, let’s give a real-life example.

The three attached files are: 
     1. the evolution icon, optimized by upstream to 32×32, and
        converted to XPM format with 1 bit of transparency (as mandated
        by the Debian menu) 
     2. the original evolution icon, scaled at 96×96 pixels (the GNOME
        shell menu size) 
     3. the XPM icon as scaled by GNOME Shell (before we rip it of the
        Debian menu) to 96×96

I don’t think “antique” is an overstatement. And I do mean it in a
pejorative way.

-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-

[evolution.xpm (image/x-xpixmap, attachment)]

[evolution-96.png (image/png, attachment)]

[evolution-xpm.png (image/png, attachment)]

Message #125 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Charles Plessy <plessy@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 11:40:12 +0100

Charles Plessy writes ("Bug#741573: Two menu systems"):
> The underlying question is: who should spend the time writing these files and
> keeping them up to date ?

The answer is, whoever wants to.  In the first instance the maintainer
may choose to do so; if they don't, then it falls to those
contributors who care about the menu.

> In the case of missing manual pages, the policy (§ 12.1) does not require the
> package maintainer to write one.

12.1 says:

  | Each program, utility, and function should have an associated manual
  | page included in the same package.

Policy does not in general say who should do any particular piece of
work.

> Therefore, I think that the “should” of §9.6, paragraph 2 should be relaxed.

I think we should use similar wording about trad menu entries to that
we use about manpages.  That means using "should" just as we do about
manpages.

Ian.

Message #130 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Josselin Mouette <joss@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 12:48:21 +0100

Josselin Mouette writes ("Bug#741573: Two menu systems"):
> Le mercredi 09 avril 2014 à 15:04 +0100, Ian Jackson a écrit : 
> > Matthias Klumpp writes ("Bug#741573: Two menu systems"):
> > > Also think about HIDPI-screens in particular, where these small icons
> > > don't make sense at all (in fact, they are so small that you often
> > > can't even tell what they display).
> > 
> > In situations like this, presumably the icons would need to be scaled.
> 
> Faced with such nonsensical words, let’s give a real-life example.

Please don't be unpleasant.

> The three attached files are: 
>      1. the evolution icon, optimized by upstream to 32×32, and
>         converted to XPM format with 1 bit of transparency (as mandated
>         by the Debian menu) 
>      2. the original evolution icon, scaled at 96×96 pixels (the GNOME
>         shell menu size) 
>      3. the XPM icon as scaled by GNOME Shell (before we rip it of the
>         Debian menu) to 96×96
> 
> I don’t think “antique” is an overstatement. And I do mean it in a
> pejorative way.

It's certainly clear that scaling a 96x96 icon down to 32x32 and back
isn't going to make it prettier.  This has little to do with the xpm
format; it's mostly because of the size restriction.

I agree that this isn't as nice as it could be.  But, as I have
explained, the underlying reason for this is that the trad menu format
is a much lower common denominator.  That comes directly from its goal
of being easily consumable by a very wide range of window managers.

If you don't like the trad menu, you don't have to use it.  Nor do you
have to do any significant amount of work to support it.  All that is
being asked is that you take other people's patches to support it.

Ian.

Message #135 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 14:10:49 +0200

Hi,

On 04/10/2014 13:48, Ian Jackson wrote:
> That comes directly from its goal
> of being easily consumable by a very wide range of window managers.

The number of consumers (window manager, menu applets, desktop
environments) is much smaller than the number of providers (in theory
every application).

Shouldn't a menu format be designed to be easy to use for the *larger*
group of application providers? Having a goal to be easy to use on the
window manager side and being less friendly[1] to the larger group seems
to be the wrong design... More so if you take into account that
application maintainers aren't really interested in menus, but people
implementing menu systems are and have to know all the details.

Ansgar

[1] This might include maintainers having to convert icons at package
    build time and so on.

Message #140 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Ansgar Burchardt <ansgar@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 13:25:25 +0100

Ansgar Burchardt writes ("Bug#741573: Two menu systems"):
> [1] This might include maintainers having to convert icons at package
>     build time and so on.

I think this is something quite trivial that can be centralised and
automated (dh_...).  Moving work from install time on the user's
computer, to build time, is generally a win.

Ian.

Message #145 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 741573@bugs.debian.org, Josselin Mouette <joss@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 05:42:40 -0700

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> If you don't like the trad menu, you don't have to use it.  Nor do you
> have to do any significant amount of work to support it.  All that is
> being asked is that you take other people's patches to support it.

That's not "should" in the Policy sense.  "Should" in the Policy sense
does, in fact, mean that you have to do work to support it, although the
level of pressure is only mild rather than at the level of rejecting the
package entirely.

I don't think we currently have a Policy term for "if you don't think this
is important for your package, or if you're just not interested in working
on it, you can ignore it, but you do need to merge patches if someone else
wants to work on it."  That would probably be useful.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #150 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 05:44:22 -0700

Charles Plessy <plessy@debian.org> writes:

> The underlying question is: who should spend the time writing these
> files and keeping them up to date ?

> In the case of missing manual pages, the policy (§ 12.1) does not
> require the package maintainer to write one.

Hm.  I have never read that section of Policy that way.  I do think that
is intended to say that the package maintainer should write one, and
that's the most common interpretation that I've seen in debian-mentors as
well.  They're not *required*, no, but that's true of any should.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #155 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 741573@bugs.debian.org, Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 05:47:09 -0700

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Ansgar Burchardt writes ("Bug#741573: Two menu systems"):

>> [1] This might include maintainers having to convert icons at package
>>     build time and so on.

> I think this is something quite trivial that can be centralised and
> automated (dh_...).  Moving work from install time on the user's
> computer, to build time, is generally a win.

Until someone has actually done that work, I believe the possibility of it
being done should be out of bounds for this Technical Committee
discussion, unless the intended implication is that the Policy maintainers
should go write such a tool (given that we're the ones affected directly
by the judgement of the TC here).

There are doubtless many things that could be done to make it easier for
maintainers who largely prefer desktop files to support the traditional
menu as well.  Part of the reason why this bug was raised in Policy in the
first place is that none of them have actually happened, and that didn't
seem that likely to change.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #160 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org

Cc: Charles Plessy <plessy@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 14:01:25 +0100

Russ Allbery writes ("Bug#741573: Two menu systems"):
> Charles Plessy <plessy@debian.org> writes:
> > The underlying question is: who should spend the time writing these
> > files and keeping them up to date ?
...
> > In the case of missing manual pages, the policy (§ 12.1) does not
> > require the package maintainer to write one.
> 
> Hm.  I have never read that section of Policy that way.  I do think that
> is intended to say that the package maintainer should write one, and
> that's the most common interpretation that I've seen in debian-mentors as
> well.  They're not *required*, no, but that's true of any should.

In practice there are lots and lots of packages in the archive with
missing manpages.

The policy goes on at some length about what to do when manpages are
missing.  It doesn't suggest that the right answer is not to upload
the package.

Of course providing a menu entry is far easier than providing a
manpage.  Some would argue it's correspondingly less useful.  I
wouldn't object to some wording in policy which made it clear that the
maintainer isn't required to do the work to provide a menu entry if
they find it inconvenient.

Ian.

Message #165 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org

Cc: Josselin Mouette <joss@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 14:02:50 +0100

Russ Allbery writes ("Bug#741573: Two menu systems"):
> That's not "should" in the Policy sense.  "Should" in the Policy sense
> does, in fact, mean that you have to do work to support it, although the
> level of pressure is only mild rather than at the level of rejecting the
> package entirely.

As I say, policy doesn't say who should do the work.  It just says
what the package should look like.

Whether a package that doesn't conform to all the "shoulds" in policy
ought to be included in the archive is surely a decision for the
packager.

If you think this needs clarifying somewhere, I don't think anyone
will object.

Ian.

Message #170 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org

Cc: Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 14:06:11 +0100

Russ Allbery writes ("Bug#741573: Two menu systems"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > Ansgar Burchardt writes ("Bug#741573: Two menu systems"):
> >> [1] This might include maintainers having to convert icons at package
> >>     build time and so on.
> > I think this is something quite trivial that can be centralised and
> > automated (dh_...).  Moving work from install time on the user's
> > computer, to build time, is generally a win.
> 
> Until someone has actually done that work, I believe the possibility of it
> being done should be out of bounds for this Technical Committee
> discussion, unless the intended implication is that the Policy maintainers
> should go write such a tool (given that we're the ones affected directly
> by the judgement of the TC here).

I think you've misunderstood me.  I felt Ansgar and I were discussing
in the abstract what would be the most optimal situation.  Certainly
I'm not saying that policy should mandate the use of anything that
doesn't currently exist.

I think that whether the general machinery for converting icons
etc. for the menu is sufficiently automatic/sophisticated is a
matter for the submitters of trad menu integration patches.

IMO if those patches aren't unreasonable then maintainers should
accept them, even if they're slightly less automatic than would be
ideal.

> There are doubtless many things that could be done to make it easier for
> maintainers who largely prefer desktop files to support the traditional
> menu as well.  Part of the reason why this bug was raised in Policy in the
> first place is that none of them have actually happened, and that didn't
> seem that likely to change.

Has anyone described any actual difficulties with supporting the
traditional menu ?

Ian.

Message #175 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 741573@bugs.debian.org, Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 06:56:53 -0700

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I think you've misunderstood me.  I felt Ansgar and I were discussing in
> the abstract what would be the most optimal situation.  Certainly I'm
> not saying that policy should mandate the use of anything that doesn't
> currently exist.

> I think that whether the general machinery for converting icons etc. for
> the menu is sufficiently automatic/sophisticated is a matter for the
> submitters of trad menu integration patches.

Oh, okay.

> IMO if those patches aren't unreasonable then maintainers should accept
> them, even if they're slightly less automatic than would be ideal.

Sure.  I don't think anyone anywhere in this discussion was advocating
rejecting contributed traditional menu entries in packages.

I do think that "should" in Policy is stronger than that, and I don't
think just weakening "should" for all of Policy is the right solution to
this bug.  I also don't know if Bill would be happy with a weaker version
of "should" that's akin to how we handle man pages in practice.

> Has anyone described any actual difficulties with supporting the
> traditional menu ?

Not that I'm personally aware of apart from there being yet one more piece
of documentation to read and one more thing to have to pay attention to
when packaging something new.  The Policy bug started with a request for
formally documenting and supporting desktop entries, and the question of
what level of requirement was appropriate for menu came out of that, not
out of a separate complaint.

One other side note: Policy has a very clear and broad mandate for what
should provide menu items, but I'm not sure that's widely known except to
the DE packagers (who, because of that mandate, generally *don't* want to
steer users towards the traditional menu).  I don't think anyone
previously has laid out the two systems the way that you did as having far
different content *by design* instead of just by accident.  I certainly
hadn't been thinking of it that way.

That may be an interesting way forward and remove a lot of tension.  The
traditional menu would be for absolutely everything and the kitchen sink,
and desktop files would only be for programs that have reasonable
integration into a more typical GUI environment.

I think drawing that distinction clearly in Policy (which it does not
currently, since it doesn't mention desktop files at all, and which I
don't think the proposed patch does either) would provide a lot more
guidance about what people should do in practice and also provide more
explicit blessing for window manager packagers who aren't interested in
the all-encompassing menu to drop it (at least by default).  That might be
a useful way to resolve this conflict and put to rest the periodic
arguments about whether, say, shells should have menu entries.  They would
have traditional menu entries but not desktop files, and we could say that
explicitly.

That leaves Policy requesting, at the level of should, that people provide
integration for something that may not be that widely used, so I'd still
like to see us develop some sort of standard wording for things that are
more "would be nice" than "this is something you need to do for your
package to be considered a good package."  Assuming, that is, Bill is okay
with putting traditional menu entries at that level.  If not, then that's
still an open question.

I think doc-base integration is a fairly similar case, BTW.  In that case,
Policy says that it is "recommended practice," which policy defines as
equivalent to "should."  If anything, doc-base is probably less used by
end users than the traditional menu.  (Personally, I think man pages are
more important than either, but man pages are also more work, and that's
to some extent personal preference.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #180 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org

Cc: Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 16:15:18 +0100

Russ Allbery writes ("Bug#741573: Two menu systems"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > IMO if those patches aren't unreasonable then maintainers should accept
> > them, even if they're slightly less automatic than would be ideal.
> 
> Sure.  I don't think anyone anywhere in this discussion was advocating
> rejecting contributed traditional menu entries in packages.

I did some searches for bugs where trad menu entries or improvements
were rejected by maintainers.  I found a great many bugs where trad
menu entries were supplied by a variety of contributors, and accepted
by maintainers.

I did find three which are arguably recalcitrant maintainers:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738027
But this is a gratifyingly low level of obstruction.

> I do think that "should" in Policy is stronger than that, and I don't
> think just weakening "should" for all of Policy is the right solution to
> this bug.  I also don't know if Bill would be happy with a weaker version
> of "should" that's akin to how we handle man pages in practice.

I think the best approach would be to make it clear somewhere in the
introduction to the policy manual that the maintainer can reasonably
decide that a package is acceptable even though it fails to comply
with a "should".

That's not to say that tools like lintian shouldn't warn about the
lack of menu entries the same way they warn about lack of manpages.

> I think doc-base integration is a fairly similar case, BTW.  In that case,
> Policy says that it is "recommended practice," which policy defines as
> equivalent to "should."  If anything, doc-base is probably less used by
> end users than the traditional menu.  (Personally, I think man pages are
> more important than either, but man pages are also more work, and that's
> to some extent personal preference.)

Right.  I think this bolsters my line of argument that policy already
uses "should" in exactly the sense which is appropriate for the Debian
menu.

> I don't think anyone previously has laid out the two systems the way
> that you did as having far different content *by design* instead of
> just by accident.  I certainly hadn't been thinking of it that way.

It seemed obvious to me after reading the bug log, which contains
conflict not just about file format and technicalities, but also about
the purpose and desired content of the menu system.

Of course the participants in the discussion were approaching the
discussion on the basis that they are arguing about what the assumed
single menu system should be like.  But it seems to me that we can
give everyone what they want by explicitly saying that these two
systems should coexist.

Of course a flipside is that it should be straightforward to cause
the trad menu to be accessible via a desktop system's menu, even if
the desktop system hides it by default.  I don't think anyone disputes
this either, though.

> That may be an interesting way forward and remove a lot of tension.  The
> traditional menu would be for absolutely everything and the kitchen sink,
> and desktop files would only be for programs that have reasonable
> integration into a more typical GUI environment.

Right.

> I think drawing that distinction clearly in Policy (which it does not
> currently, since it doesn't mention desktop files at all, and which I
> don't think the proposed patch does either) would provide a lot more
> guidance about what people should do in practice and also provide more
> explicit blessing for window manager packagers who aren't interested in
> the all-encompassing menu to drop it (at least by default).  That might be
> a useful way to resolve this conflict and put to rest the periodic
> arguments about whether, say, shells should have menu entries.  They would
> have traditional menu entries but not desktop files, and we could say that
> explicitly.

Exactly.  I think the best way to deal with this is to have two
separate policy sections, one for each menu system.  That way there
won't have to be any disputes about what the text ought to say.

Each of those two sections should use the same "should provide"
wording, qualified by the appropriate explanation of the intended
scope of that menu.

Ian.

Message #185 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bdale Garbee <bdale@gag.com>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org, Russ Allbery <rra@debian.org>

Cc: Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 09:38:28 -0600

[Message part 1 (text/plain, inline)]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I did find three which are arguably recalcitrant maintainers:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738027
> But this is a gratifyingly low level of obstruction.

Yep.

And, actually, it appears that only one of those, 609807, included
something like a patch... and that one just hasn't been responded to.
The other two were requests for the maintainer to do work which were
rejected, and thus don't really tell us whether an offered patch would
have been accepted or rejected.

> Of course the participants in the discussion were approaching the
> discussion on the basis that they are arguing about what the assumed
> single menu system should be like.  But it seems to me that we can
> give everyone what they want by explicitly saying that these two
> systems should coexist.

It disappoints me on some philosophical level to think that we can't
unify the two somehow, but I agree that given the current circumstances
and tools available that treating desktop files as an addition to and
not a replacement for trad menu entries makes sense.

Bdale

[Message part 2 (application/pgp-signature, inline)]

Message #190 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sune Vuorela <sune@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 18:25:43 +0100

Sune Vuorela writes ("Re: Bug#741573: Two menu systems"):
> if it takes 5 minutes to write a menu file and 5 minutes to switch to one of 
> those 'old style' window managers and test that it shows up as it should, it 
> is 3000 minutes. Or 1 hour per week in a year.

I don't think you need to test it, if you don't want to.  For
something like a menu file it is perfectly fine to simply take the
patch, as-is, when it's provided.

Really, that should be no more than a simple review, and applying the
patch to your package's vcs.  It shouldn't take you more than a couple
of minutes at most - probably less.

> And I guess that on some uploads, it should be tested again that it
> still shows up as it should. if that happens once pr year pr
> package, it is 30 minutes pr week pr year.

I think you are perfectly entitled to let the people who care about
the Debian menu take care of that testing.

> And if one shouldn't 'consume' the menu, why should one provide data for it? 
> [2]

Different people have different views about which menu is useful.

Clearly one should have the _ability_ to consume the menu.  Whether to
do so by default is a decision for the maintainer of the environment
in question.

Ian.

Message #195 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 19:17:59 +0200

On Thursday 10 April 2014 14:06:11 Ian Jackson wrote:
> Has anyone described any actual difficulties with supporting the
> traditional menu ?

I am in the uploaders field of packages that probably requires 300 menu files to 
be available and of one consumer of "menus".

if it takes 5 minutes to write a menu file and 5 minutes to switch to one of 
those 'old style' window managers and test that it shows up as it should, it 
is 3000 minutes. Or 1 hour per week in a year. And I guess that  on some 
uploads, it should be tested again that it still shows up as it should. if 
that happens once pr year pr package, it is 30 minutes pr week pr year.

Isn't that time better spent elsewhere?

From the 'consumer' point of view. I have been of the opinion that as long as 
the Debian menu is *the* thing documented in the policy, consumers should 
display the Debian menu. I even at one point put my time where my mouth was 
and wrote the desktop2menu tool available in devscripts to help the Debian 
menu.

But for various reasons[0], I don't think the Debian Menu is the thing to show 
to most users. And we should get policy fixed to allow this, which is why I 
filed the initial bug+patch that later actually got consensus thru the normal 
policy process, and was heading into the policy until Bill Allombert short 
circuited the policy process in order to defend his kingdom. 

And if one shouldn't 'consume' the menu, why should one provide data for it? 
[2]

No. It is not difficult. It is just work. And give a bad experience to users.

And once again, I'll link to the tool by Arch that builds menus based upon the  
.desktop files that fits in many 'old style' window managers.  
https://wiki.archlinux.org/index.php/Xdg-menu

/Sune

[0] 
 - it is ugly (see the icon format subthread, for example)
 - it duplicates the entries already provided by the desktop files
 - the menu-xdg package generates categories that icon themes doesn't have 
icons for and the menu-xdg maintainer refuses to fix it
 - it contains useless entries for many things that helps hiding what you look 
for [1]
 - having two similar menu structures is confusing.

[1] Shells and interactive interpreters and such.

[2] afaik, the gnome maintainers have added code to the gnome menu building 
thing that does foreach desktopfile in desktopfiles { 
if(!desktopfile.path.contains("menu-xdg")) addtomenu(desktopfile); }
I am planning something similar for the kdelibs menu building code.

-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Message #200 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 741573@bugs.debian.org, Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 11:47:31 -0700

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Bug#741573: Two menu systems"):

>> I do think that "should" in Policy is stronger than that, and I don't
>> think just weakening "should" for all of Policy is the right solution
>> to this bug.  I also don't know if Bill would be happy with a weaker
>> version of "should" that's akin to how we handle man pages in practice.

> I think the best approach would be to make it clear somewhere in the
> introduction to the policy manual that the maintainer can reasonably
> decide that a package is acceptable even though it fails to comply with
> a "should".

I am opposed to doing this.  I think a perusal of Policy will make clear
that this will substantially weaken a variety of other rules that we do
not want weakend in this way.

There are two rough "types" of should in writing a document of this sort:
things that you really, for lack of a better word, *should* be doing, but
which may have some corner cases or special exceptions, and things that
are basically optional features that we're encouraging but not requiring.
They need to be talked about in two different ways, since they're not the
same thing.  I believe (although have not gone back to count) that most of
the uses of "should" in Policy at present are of the former type, not the
latter.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #205 received at 741573@bugs.debian.org (full text, mbox, reply):

From: "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer@gmail.com>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 18:31:14 -0300

[Message part 1 (text/plain, inline)]

On Thursday 10 April 2014 09:38:28 Bdale Garbee wrote:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > I did find three which are arguably recalcitrant maintainers:
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738027
> > 
> > But this is a gratifyingly low level of obstruction.
> 
> Yep.
> 
> And, actually, it appears that only one of those, 609807, included
> something like a patch... and that one just hasn't been responded to.

And that has a reason:

<http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-qt-kde@lists.debian.org;dist=unstable>

Now if I add to that the reasons Sune posted in [0], I really won't bother in 
taking a look at it. Don't get me wrong, adding a patch will certainly 
wouldn't be a problem if there wasn't such a big queue of more important stuff 
to fix.

[0] <https://lists.debian.org/debian-ctte/2014/04/msg00031.html>

-- 
A child of five could understand this.
Fetch me a child of five.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #210 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org

Cc: Russ Allbery <rra@debian.org>, Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 15:19:09 -0700

[Message part 1 (text/plain, inline)]

Hi Ian,

On Thu, Apr 10, 2014 at 04:15:18PM +0100, Ian Jackson wrote:

> Of course the participants in the discussion were approaching the
> discussion on the basis that they are arguing about what the assumed
> single menu system should be like.  But it seems to me that we can
> give everyone what they want by explicitly saying that these two
> systems should coexist.

I haven't had a chance to formulate my thoughts on the wider question yet,
but I wanted to respond specifically to this.

It is *not* giving everyone what they want to let these two systems coexist.

 - What maintainers want is to have to spend as little effort as possible
   on maintaining menu entries for their software (so one system is better
   than two for this; and something upstream is better than not)
 - What users want is to be able to find the software installed on their
   Debian systems through the GUI.
 - What *I* want is for the TC to take a principled stand on the point that
   the policy manual exists to describe distribution-wide integration
   policies, instead of taking a "there's more than one way to do it" easy
   way out.

The Debian menu system was created out of recognition that there is a
many-to-many mapping between applications and desktop environments (or
window managers or what-have-you), and aimed to solve this problem by
providing a common format that can be used as a nexus between them.  Given
that the two most widely-used desktop systems on Debian no longer support
the Debian menu system, it is a failure in this regard.  But this is still
the goal that should be set in policy, and not one I believe we should
compromise on.

> Of course a flipside is that it should be straightforward to cause
> the trad menu to be accessible via a desktop system's menu, even if
> the desktop system hides it by default.  I don't think anyone disputes
> this either, though.

I think there should be a single menu system in Debian, and that it should
have provisions for "preferred" applications on different desktop
environments, like .desktop files currently do; but that the UI should also
expose "non-preferred" applications in some suitable form.  Over the
lifetime of this disagreement, I have repeatedly heard claims that the
Debian menu system should not be exposed at all in e.g. the GNOME desktop
because it's "full of junk" (paraphrased).  If there are problems with the
way applications are being categorized, or if applications are being
included in ways that we think don't make sense on a graphical desktop, then
we should address those problems through the policy process - we shouldn't
simply have desktops deciding to opt out of showing the user the software
they've chosen to install.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #215 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 741573@bugs.debian.org, Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 15:29:58 -0700

Steve Langasek <vorlon@debian.org> writes:

>  - What *I* want is for the TC to take a principled stand on the point that
>    the policy manual exists to describe distribution-wide integration
>    policies, instead of taking a "there's more than one way to do it" easy
>    way out.

This is what I'd prefer too.  I guess I'm so used to losing on this point
in a Policy context for various reasons, some quite difficult to solve
(such as the continued existence of both shlibs and symbols), that I give
up on it easily.  But I do think Debian's most common failure mode is
that, when asked to choose between A and B, we deploy A, B, C, and Z.

It's a failure mode that's also a strength, of course, since it makes us
flexible.  But I watch debian-mentors closely, and I have to say that
we're setting our bar of entry extremely high, and in ways that I'm not
sure are really that helpful.  It would be one thing if the bar was mostly
around very high-quality core packaging, but a lot of reviews mention all
sorts of things that Lintian complains about (menu integration, doc-base
integration, man pages, language extensions on scripts, arch-independent
files in /usr/share, missing upstream NEWS files, missing upstream signing
keys, etc.) that are what I would call "advanced quality of
implementation" issues, and that I'm not sure we want to make quite as
visible as they currently are.

Don't get me wrong: I care about a lot of those things too, and over time
I try to implement All The Things in my packages.  But I also really
*enjoy* that sort of exacting attention to detail, and while that's a nice
quality for us to encourage, it's not clear to me that we want to make
that the bar to entry.  And that's how it's being perceived right now.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #220 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: Didier 'OdyX' Raboud <odyx@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 10 Apr 2014 16:17:00 -0700

[Message part 1 (text/plain, inline)]

On Wed, Apr 09, 2014 at 01:27:46PM -0400, Sam Hartman wrote:

> Thanks for bringing this issue back to the question that was brought to
> the TC.

> The discussion so far on this bug has focused on discussing what the
> right  menu policy is for Debian.

> That, however was not the question that was brought to the TC.

It is my understanding that this is exactly the question that has been
referred to the TC, because the default policy process only works when there
is a consensus - and there is not a consensus here.  So it necessarily falls
to the TC to decide what the policy should be, in the absence of this
consensus; and while the TC should not do detailed design work, it would
also be counterproductive to try to limit ourselves to giving all answers in
the form of a boolean.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #225 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Stuart Prescott <stuart@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 12:43:48 +1000

Ian Jackson wrote:
> I think you are perfectly entitled to let the people who care about
> the Debian menu take care of that testing.

As others have pointed out, that's a level a lot lower in everyone's 
current understanding of what "should" means in the context of policy. This 
may not be what was intended by the policy authors, but I think the average 
maintainer reads "should" as something that *they* are supposed to do 
unless they have a good technical reason. As Russ has pointed out, that is 
certainly how it is presented to new maintainers in our mentors process and 
there is an expectation there that the maintainer (not some other 3rd 
party) is will ensure that their packages conform to the million little 
"should"s in policy.

Policy already lists "may" as the word to use for things that are optional. 
To me, Ian's statement above sounds a lot like a suggestion that packages 
*may* provide trad menu files, not *should* provide.

Stuart

-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart@nanonanonano.net
Debian Developer   http://www.debian.org/         stuart@debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Message #230 received at 741573@bugs.debian.org (full text, mbox, reply):

From: "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer@gmail.com>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 00:03:19 -0300

[Message part 1 (text/plain, inline)]

On Friday 11 April 2014 12:43:48 Stuart Prescott wrote:
> Ian Jackson wrote:
> > I think you are perfectly entitled to let the people who care about
> > the Debian menu take care of that testing.
> 
> As others have pointed out, that's a level a lot lower in everyone's
> current understanding of what "should" means in the context of policy. This
> may not be what was intended by the policy authors, but I think the average
> maintainer reads "should" as something that *they* are supposed to do
> unless they have a good technical reason. As Russ has pointed out, that is
> certainly how it is presented to new maintainers in our mentors process and
> there is an expectation there that the maintainer (not some other 3rd
> party) is will ensure that their packages conform to the million little
> "should"s in policy.
> 
> Policy already lists "may" as the word to use for things that are optional.
> To me, Ian's statement above sounds a lot like a suggestion that packages
> *may* provide trad menu files, not *should* provide.

And if I'm not mistaken, that is precisely what was done until Bill reverted 
the patch.

I do also agree with Russ here that redefining "should" is not a good idea at 
all, specially because most of us understand that as Stuart just wrote (with 
some little rephrasing):

 should: "something that a maintainer is supposed to do unless they have a
 good technical reason"


-- 
"Los promotores del software privativo demonizan algo tan básico y ético como
el hecho de compartir imponiendo términos como el de 'pirata'. Equiparan
ayudar al prójimo con atacar barcos. Cuando me preguntan qué pienso de la
piratería musical e informática digo que atacar barcos es muy malo y,
que yo sepa, los piratas no usan computadoras.”
  Richard Stallman, 05/11/2008, anexo de la Cámara de Diputados, Argentina

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #235 received at 741573@bugs.debian.org (full text, mbox, reply):

From: "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer@gmail.com>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 00:10:43 -0300

[Message part 1 (text/plain, inline)]

On Thursday 10 April 2014 18:25:43 Ian Jackson wrote:
> Sune Vuorela writes ("Re: Bug#741573: Two menu systems"):
> > if it takes 5 minutes to write a menu file and 5 minutes to switch to one
> > of those 'old style' window managers and test that it shows up as it
> > should, it is 3000 minutes. Or 1 hour per week in a year.
> 
> I don't think you need to test it, if you don't want to.  For
> something like a menu file it is perfectly fine to simply take the
> patch, as-is, when it's provided.

I do understand your POV in that "a menu file it's simple enough" [simple] but 
I also read a lot of people complaining about us maintainers not testing our 
packages [0] and now we are suggested to not test a patch, even if it's small 
or "simple".

So, for the sake of coherence, I will not buy that argument.

[simple] as long as you remember the format. I don't.

[0] I do also recognize that sometimes it's practically impossible to test 
everything, and there is always the human factor to have mistakes.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #240 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Steve Langasek <vorlon@debian.org>, 741573@bugs.debian.org

Cc: Russ Allbery <rra@debian.org>, Ansgar Burchardt <ansgar@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 11:55:11 +0100

Steve Langasek writes ("Bug#741573: Two menu systems"):
...
>  - What *I* want is for the TC to take a principled stand on the point that
>    the policy manual exists to describe distribution-wide integration
>    policies, instead of taking a "there's more than one way to do it" easy
>    way out.

Taken to its logical conclusion, this suggests that we should throw
Python out of the archive because Perl does much of the same tasks.

My view is that the trad and desktop menus serve different functions
for different sets of users.  They are superficially similar but for
the reasons I have explained merging them doesn't make sense.

>  Over the lifetime of this disagreement, I have repeatedly heard
> claims that the Debian menu system should not be exposed at all in
> e.g. the GNOME desktop because it's "full of junk" (paraphrased).

But it is this very comprehensiveness which makes the menu valuable to
other users (such as Matthew Vernon who has posted earlier in this
thread).

Now it might be possible to have one file format and some kind of
filtering approach so that users who want to see a comprehensive menu
can have one, and users who want a more aggressively curated menu see
a subset.

But there are other differences between the two menu systems: they
tend to be preferred by different groups of people who use different
menu consumers, with different capabilities and restrictions.  Even
leaving aside differences of preference in categorisation, the
categorisation of a comprehensive menu requires a different approach
to the categorisation of smaller menu.

The two communities seem even to have a different view about what
should go in the name of a menu entry.  Desktop environment folks seem
to prefer to emphasise descriptions of the functionality ("image
viewer") whereas in the trad menu the names of programs are more
prominent.

So I think even if these two systems used identical technology, you
would still end up with either two parallel sets of menu entry files,
or one set of files containing two parallel sets of metadata (two
titles, two categorisations, different filtering information, etc.)

Under these circumstances it doesn't seem sensible to me to try to
enforce a merger, even from a technical point of view.

(Of course we could have only one set of metadata and invite a battle
between the two camps to make the one menu look like they think it
ought to be, which would be even worse.)

Ian.

Message #245 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Stuart Prescott <stuart@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 12:04:12 +0100

Stuart Prescott writes ("Bug#741573: Two menu systems"):
> Ian Jackson wrote:
> > I think you are perfectly entitled to let the people who care about
> > the Debian menu take care of that testing.
> 
> As others have pointed out, that's a level a lot lower in everyone's 
> current understanding of what "should" means in the context of policy. This 
> may not be what was intended by the policy authors, but I think the average 
> maintainer reads "should" as something that *they* are supposed to do 
> unless they have a good technical reason. As Russ has pointed out, that is 
> certainly how it is presented to new maintainers in our mentors process and 
> there is an expectation there that the maintainer (not some other 3rd 
> party) is will ensure that their packages conform to the million little 
> "should"s in policy.
> 
> Policy already lists "may" as the word to use for things that are optional. 
> To me, Ian's statement above sounds a lot like a suggestion that packages 
> *may* provide trad menu files, not *should* provide.

The problem with "may" is that it suggests that there can be
situations where it is better not to provide a trad menu entry even in
cases where the policy on trad menu entries currently says that one
"should".  It implies that a judgement needs to be made between two
equally good options.

I don't imagine you're proposing changing the wording of the sections
of policy on doc-base entries, manpages, etc. to "may".

If we need to distinguish situations where we expect the maintainer to
normally do the work before uploading, and ones where we don't
necessarily, perhaps we need a new wording.

Ian.

Message #250 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 741573@bugs.debian.org, Didier 'OdyX' Raboud <odyx@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 08:44:53 -0400

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

    Steve> On Wed, Apr 09, 2014 at 01:27:46PM -0400, Sam Hartman wrote:
    >> Thanks for bringing this issue back to the question that was
    >> brought to the TC.

    >> The discussion so far on this bug has focused on discussing what
    >> the right menu policy is for Debian.

    >> That, however was not the question that was brought to the TC.

    Steve> It is my understanding that this is exactly the question that
    Steve> has been referred to the TC, because the default policy
    Steve> process only works when there is a consensus - and there is
    Steve> not a consensus here.  

It's my understanding of whether there is a consensus was in debate.
Russ believed (and made a call) that there was a consensus.

If the TC  looks at the discussion and concludes that "no, nope not a
consensus there," then I'll be entirely  happy with the sort of
discussions the TC is happening now.
Interestingly, from some side comments Ian has made I actually suspect
he's looked enough that he at least has come to the conclusion that "no,
not a consensus here," but he's never said that.

I'd feel a lot happier if some TC members would actually state opinions
on whether as Bill claimed there are substantial non-addressed issues
brought up in the policy process.
If so, then deciding on the base issue makes sense.

If, as Russ claimed, a consensus was reached in a properly conducted
policy process, then I strongly disagree with the approach the TC is
taking.  I think it creates significant harm for the project as a whole
when the TC does not generally respect the processes and work of the
rest of the project.

In this particular instance it's really frustrating to those who spent a
long time in the policy discussion and who believed they had reached a
conclusion.  Having been in similar situations in the past it is
frustrating when someone comes into review things and does not respect
the time and energy.  Why should I participate in discussions in the
future trying to find and build a compromise if those discussions will
ultimately be overruled by a body who will not work with them?  It tends
to create feelings of frustration and powerlessness rather than feelings
of pride and ownership when we think about our work.

Respecting the time and energy  doesn't mean agreeing with the result.
It does mean taking the time to understand the result.  Having been in
similar situations I felt a lot better when my work was reviewed and
someone came along, carefully considered the discussion and concluded
that we hadn't actually reached a consensus.  At least they respected
our work enough to evaluate it.  We all participate enough in technical
work that we know we'll be wrong.  Wrong is OK; not worth being listened
to promotes veryp negative feelings.

So, if you've reviewed this enough to support Bill's claim that there
isn't a consensus because there are substantial objections raised in the
discussions and not addressed, then please say that.  If you have not
reviewed things sufficiently to make that conclusion, then I ask you and
the rest of the TC to take sufficient steps that such a review happen.

Message #255 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>, Didier 'OdyX' Raboud <odyx@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 14:18:15 +0100

Sam Hartman writes ("Bug#741573: Two menu systems"):
> If, as Russ claimed, a consensus was reached in a properly conducted
> policy process, then I strongly disagree with the approach the TC is
> taking.  I think it creates significant harm for the project as a whole
> when the TC does not generally respect the processes and work of the
> rest of the project.

It is part of the job of the TC to resolve disputes about the content
of technical policy.  We do that not simply by observing whether some
proper process was followed.  We do it by examining the issue on the
merits.

> Respecting the time and energy doesn't mean agreeing with the result.
> It does mean taking the time to understand the result.

I have read the entire bug log.  It is mostly based on that reading
that I have come to the view I now hold.

> So, if you've reviewed this enough to support Bill's claim that there
> isn't a consensus because there are substantial objections raised in the
> discussions and not addressed, then please say that.  If you have not
> reviewed things sufficiently to make that conclusion, then I ask you and
> the rest of the TC to take sufficient steps that such a review happen.

It is not the job of the TC to decide whether there was or was not
consensus.  It is the job of the TC to decide in cases of dispute what
the best technical approach is.

It is clear that there is a dispute here; a dispute which has been
referred to the TC.  That means that it is the TC's job now to decide
on the merits.

Having read the bug log I disagree with the policy change that was
made (and then reverted).  I disagree with it for the reasons stated
by Bill and for reasons based on my own analysis of the situation as I
have set out in this thread.  I disagree with the change on
substantive grounds, not on the grounds of any procedural complaint.

I disagree with the policy change despite the substantive arguments
made in the bug log - arguments which I have, obviously, read and
considered.

> If the TC looks at the discussion and concludes that "no, nope not a
> consensus there," then I'll be entirely happy with the sort of
> discussions the TC is happening now.

In deciding what the contents of the policy should be, it is not
necessary or desirable for the TC to consider whether there was
consensus at the time the policy change was committed (or, for that
matter, reverted).

>  Having been in similar situations I felt a lot better when my work
> was reviewed and someone came along, carefully considered the
> discussion and concluded that we hadn't actually reached a
> consensus.  At least they respected our work enough to evaluate it.
> We all participate enough in technical work that we know we'll be
> wrong.  Wrong is OK; not worth being listened to promotes veryp
> negative feelings.

The question of consensus, or lack of it, is irrelevant.

Listening to the arguments, and evaluating the proposals on their
merits, is exactly what we are doing.

> So, if you've reviewed this enough to support Bill's claim that there
> isn't a consensus because there are substantial objections raised in the
> discussions and not addressed, then please say that.

You seem to be using a strange definition of consensus that suggests a
consensus might exist despite objections, if those objections have
been "addressed" (to the satisfaction of some participants but not to
the satisfaction of the objectors).  But, this is not relevant to the
TC so there is no need to say more about it.


Ultimately you seem to be seeking a remedy for what you see as a
process violation.  The TC is not going to help you with that.  As I
say, it is quite common for disputes to end up at the TC after one or
both sides have escalated to questionable actions.

In these situations the TC will try to decide on the underlying
technical issue, rather than seeking to judge people's past actions.

Thanks,
Ian.

Message #260 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 741573@bugs.debian.org, Steve Langasek <vorlon@debian.org>, Didier 'OdyX' Raboud <odyx@debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 09:34:12 -0400

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:


    >> So, if you've reviewed this enough to support Bill's claim that
    >> there isn't a consensus because there are substantial objections
    >> raised in the discussions and not addressed, then please say
    >> that.  If you have not reviewed things sufficiently to make that
    >> conclusion, then I ask you and the rest of the TC to take
    >> sufficient steps that such a review happen.

    Ian> It is not the job of the TC to decide whether there was or was
    Ian> not consensus.  It is the job of the TC to decide in cases of
    Ian> dispute what the best technical approach is.

There are many factors the TC can use to decide what technical policy to
set and whether to set technical policy.

I'm disappointed when I hear you describe such a narrow interpretation
for what you want the TC to do, because as I've explained such a narrow
interpretation is vin my opinion very harmful to the project.  I'm quite
confident the TC has the constitutional authority to do what I'm
suggesting.

However at this point we're repeating ourselves.  I understand you that
the TC has the authority to do as you propose and that you believe
that's the best course of action.  On that point we disagree in the
strongest possible terms.

--Sam

Message #265 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Stuart Prescott <stuart@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 23:34:11 +1000

On Fri, 11 Apr 2014 21:04:12 Ian Jackson wrote:
> Stuart Prescott writes ("Bug#741573: Two menu systems"):
> > Ian Jackson wrote:
> > > I think you are perfectly entitled to let the people who care about
> > > the Debian menu take care of that testing.
> > 
> > As others have pointed out, that's a level a lot lower in everyone's
> > current understanding of what "should" means in the context of policy.
> > This may not be what was intended by the policy authors, but I think the
> > average maintainer reads "should" as something that *they* are supposed
> > to do unless they have a good technical reason. As Russ has pointed out,
> > that is certainly how it is presented to new maintainers in our mentors
> > process and there is an expectation there that the maintainer (not some
> > other 3rd party) is will ensure that their packages conform to the
> > million little "should"s in policy.
> > 
> > Policy already lists "may" as the word to use for things that are
> > optional. To me, Ian's statement above sounds a lot like a suggestion
> > that packages *may* provide trad menu files, not *should* provide.
> 
> The problem with "may" is that it suggests that there can be
> situations where it is better not to provide a trad menu entry even in
> cases where the policy on trad menu entries currently says that one
> "should".  It implies that a judgement needs to be made between two
> equally good options.
> 
> I don't imagine you're proposing changing the wording of the sections
> of policy on doc-base entries, manpages, etc. to "may".

Indeed I am not proposing that. I believe those are things that the maintainer 
should provide as part of the package.

> If we need to distinguish situations where we expect the maintainer to
> normally do the work before uploading, and ones where we don't
> necessarily, perhaps we need a new wording.

I think we've already got that in "should" and "may".

Stuart


-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart@nanonanonano.net
Debian Developer   http://www.debian.org/         stuart@debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Message #270 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Stuart Prescott <stuart@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 15:23:06 +0100

Stuart Prescott writes ("Bug#741573: Two menu systems"):
> On Fri, 11 Apr 2014 21:04:12 Ian Jackson wrote:
> > I don't imagine you're proposing changing the wording of the sections
> > of policy on doc-base entries, manpages, etc. to "may".
> 
> Indeed I am not proposing that. I believe those are things that the
> maintainer should provide as part of the package.

Then in disagree.  But I think I disagree with you about manpages more
than I do about menu entries.

In practice the archive is absolutely full of programs without
manpages and it doesn't make sense to insist that every maintainer
preparing a package should also write a manpage.

Writing manpages is a lot of work, and is also a distinct skill that
many packages don't necessarily have.  (The mechanisms for trying to
generate manpages automatically are fragile and unpleasant and
generate rather poor output, so that's not really an answer.)

The upshot is that we don't currently insist that maintainers provide
manpages.  I have never been criticised by anyone for uploading or
sponsoring anything with missing manpages.  I don't think anyone else
should be criticised for that.  (Of course sometimes people have filed
bugs providing manpages, which is very welcome.)

Ian.

Message #275 received at 741573@bugs.debian.org (full text, mbox, reply):

From: "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer@gmail.com>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 11:43:13 -0300

[Message part 1 (text/plain, inline)]

On Friday 11 April 2014 15:23:06 Ian Jackson wrote:
[snip] 
> The upshot is that we don't currently insist that maintainers provide
> manpages.  I have never been criticised by anyone for uploading or
> sponsoring anything with missing manpages.  I don't think anyone else
> should be criticised for that.  (Of course sometimes people have filed
> bugs providing manpages, which is very welcome.)

Then we have a "double standard" here. For some cases we (as in "the project") 
consider "should" as Stuart and I described it before, but we do *also* 
consider it a "may" for some cases, as Ian has just pointed it out.

So we either need a new word between "should" and "may" or sincere us and use 
"may" for manpages too. I would prefer the latest, but I understand if someone 
disagrees.

-- 
Simulations are not data. In God we trust, all the others must supply data.
 Walter Opyd, "Show Me The Data" IEEE Spectrum's reader's comments,
 http://www.spectrum.ieee.org/nov04/4004

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #280 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer@gmail.com>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 16:10:01 +0100

Lisandro Damián Nicanor Pérez Meyer writes ("Bug#741573: Two menu systems"):
> Then we have a "double standard" here. For some cases we (as in "the
> project") consider "should" as Stuart and I described it before, but
> we do *also* consider it a "may" for some cases, as Ian has just
> pointed it out.

Can you come up with any examples where "should" is used in a way that
_does not_ permit a maintainer to disregard it if it appears to be a
more work than they care to put in ?

I had a quick look at an arbitrarily chosen section (10, as it
happens, on "files"), and there are a lot of uses of "should" which
are probably bugs if not followed - but none of those are any
particular effort to comply with.

Here are the shoulds that seem to me like they might involve some
> actual effort:

  10.1
  | builds to include debugging info by default
  | builds should turn on warnings

  10.2
  | static libraries not to use -fPIC unless discussed
  | scripts to use set -e (not limited to Debian-authored ones!)
  | perl scripts to check errors (not limited to Debian-authored ones!)
  | avoid [t]csh for scripting (not limited to Debian-authored ones!)

  10.7.1
  | script containing config should be treated as config

  [ok, bored now]

There are a couple of these that probably should be "must".  For the
rest it is IMO acceptable to upload a package which violates them, if
the maintainer doesn't feel like tackling that particular problem.

Foe example, if the upstream build system is particularly intractable
and makes it difficult to sanely specify compiler flags, then
it's acceptable (but of course undesirable) to let the upstream build
system have its way.  If the upstream package comes with tcsh scripts
or perl scripts that have shoddy error handling or sh scripts that
don't say set -e, those things are probably bugs - but I don't
necessarily expect the maintainer to fix them all.

Ian.

Message #285 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 14:16:09 -0300

[Message part 1 (text/plain, inline)]

On Friday 11 April 2014 16:10:01 you wrote:
> Lisandro Damián Nicanor Pérez Meyer writes ("Bug#741573: Two menu systems"):
> > Then we have a "double standard" here. For some cases we (as in "the
> > project") consider "should" as Stuart and I described it before, but
> > we do *also* consider it a "may" for some cases, as Ian has just
> > pointed it out.
> 
> Can you come up with any examples where "should" is used in a way that
> _does not_ permit a maintainer to disregard it if it appears to be a
> more work than they care to put in ?

Sure: that's seems to be the general understanding of the word: someone 
already gave the debian-mentors example, Stuart had the same understanding, I 
had the same understanding. And this seems to be one of the root causes of all 
this mess. Do we have a general misunderstanding of the real meaning of the 
word? Excellent, let's make it clear with this discussion! [0]

Now allow me to use "should" as you understand it, and let me express, for the 
sake of adding another possibility, another "solution": maintainers "should" 
provide either the "trad" or "desktop" menu, and once they pick one of them 
the other becomes a "may".

There some things to note here:

- I have never thought of this solution before because , as it stands out, we 
seems to be having different interpretations of the same word.

- It will also fall under what Russ expressed in [1]

- Yes, this means not everybody will get their preferred menu system in all 
the packages.

[0] I also can understand if it's "clear" for you, but I'm pretty sure that's 
not the common case.
[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#215>

-- 
Antiguo proverbio de El Machi: "Dado el apropiado grado de profundidad, la
ineptitud es indistinguible del sabotaje"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #290 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 18:25:01 +0100

Lisandro Damián Nicanor Pérez Meyer writes ("Bug#741573: Two menu systems"):
> On Friday 11 April 2014 16:10:01 you wrote:
> > Can you come up with any examples where "should" is used in a way that
> > _does not_ permit a maintainer to disregard it if it appears to be a
> > more work than they care to put in ?
> 
> Sure: that's seems to be the general understanding of the word:
> someone already gave the debian-mentors example,

I'm afraid that's not what I meant by an example.  I meant a
particular use of the word in the policy document.

>  Stuart had the same understanding, I had the same
> understanding. And this seems to be one of the root causes of all
> this mess. Do we have a general misunderstanding of the real meaning
> of the word? Excellent, let's make it clear with this discussion!
> [0]

At the very least there is already some confusion here because
different people are saying different things about (for example)
doc-base entries and manpages.

> Now allow me to use "should" as you understand it, and let me
> express, for the sake of adding another possibility, another
> "solution": maintainers "should" provide either the "trad" or
> "desktop" menu, and once they pick one of them the other becomes a
> "may".

I don't think this is a sensible thing to say.  In my view the two
systems aren't alternatives in that way so an entry in one system
doesn't affect the need (or lack of need) for an entry in the other.

If one wanted to unify the two systems idea then what you suggest is
one possible approach to that but for the reasons I have explained I
don't think trying to unify them is a good idea.

Ian.

Message #295 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 14:52:15 -0300

[Message part 1 (text/plain, inline)]

On Friday 11 April 2014 18:25:01 you wrote:
> Lisandro Damián Nicanor Pérez Meyer writes ("Bug#741573: Two menu systems"):
> > On Friday 11 April 2014 16:10:01 you wrote:
> > > Can you come up with any examples where "should" is used in a way that
> > > _does not_ permit a maintainer to disregard it if it appears to be a
> > > more work than they care to put in ?
> > 
> > Sure: that's seems to be the general understanding of the word:
> > someone already gave the debian-mentors example,
> 
> I'm afraid that's not what I meant by an example.  I meant a
> particular use of the word in the policy document.

I got that and I understand that you have a point policy-wide. But (see 
below)...

> >  Stuart had the same understanding, I had the same
> > understanding. And this seems to be one of the root causes of all
> > this mess. Do we have a general misunderstanding of the real meaning
> > of the word? Excellent, let's make it clear with this discussion!
> > [0]
> 
> At the very least there is already some confusion here because
> different people are saying different things about (for example)
> doc-base entries and manpages.

That's my point. And if the policy wants to express something that at least 
some of us (which I thing it's not a small group) understand differently, it's 
clear we are going to have this kind of discussions.

> > Now allow me to use "should" as you understand it, and let me
> > express, for the sake of adding another possibility, another
> > "solution": maintainers "should" provide either the "trad" or
> > "desktop" menu, and once they pick one of them the other becomes a
> > "may".
> 
> I don't think this is a sensible thing to say.  In my view the two
> systems aren't alternatives in that way so an entry in one system
> doesn't affect the need (or lack of need) for an entry in the other.

Well, at least we know we disagree here :)
 
> If one wanted to unify the two systems idea then what you suggest is
> one possible approach to that but for the reasons I have explained I
> don't think trying to unify them is a good idea.

Agree to the first part, and forcibly agree to the second because, at least in 
the implementation side, to disagree I should be ready to provide patches, 
which I'm currently not able to do.

Note I'm not considering non-technical issues for the second part (if there is 
any, I would need to properly re read that part to decide).

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #300 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 741573@bugs.debian.org, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 11 Apr 2014 12:32:51 -0700

So, to take a step back, I think Ian is arguing that, by declaring the
traditional menu system a "should," he's not introducing a problem into
Policy that doesn't already exist, because our current use of "should" is
all over the map.

I agree with that statement as far as it goes, but I don't think it's a
very useful observation.  Because usage of "should" is currently all over
the map, it doesn't provide any clear guidance to the packager, which is
what the goal should be.

When working on a section of Policy, I try to fix issues like that when we
see them.  There are various "should" requirements in Policy that I think
are actually wishlist bugs, among them man pages and doc-base integration.
I don't believe those should share a word with things I would file as
important bugs.  That's a long-standing bug in Policy that needs to get
fixed.

I think it's up to the TC to figure out what the requirements on
maintainers are for the two separate menu systems in Debian at the moment,
and to express those in some clear way so that the project knows what the
requirements are and to what extent we are holding maintainers to them.  I
don't think it's up to the TC to decide how Policy handles normative
language.

So, I think the questions before the TC are:

1. Should programs that make sense in the context of a typical DE (I
   realize there's some fuzziness around this) all have desktop files?  If
   so, what level of Policy requirement should that be?  (Please be more
   specific than "should" -- maybe talk in terms of expected bug
   severities?  For reference, I consider man pages and doc-base
   integration to be a wishlist bug.)

2. What level of Policy requirement is providing traditional menu files in
   individual packages, using the same terminology?

Things that I don't think are TC issues:

* Whether desktop files should be documented in Policy at all.  There
  appears to be consensus that they should be, and I don't think anyone is
  disagreeing with that consensus, so there is no dispute there.

* How Policy should formally represent the distinction between different
  levels of requirements.  I respectfully suggest that this is a question
  of the maintenance and style of the Policy documentation, not a question
  of technical policy for the project, and is therefore a matter for the
  Policy Editors to decide, not the TC.  What we're looking for from the
  TC is clear guidance on what the requirements are and what level of
  severity those requirements have.  We clearly need to find some way to
  represent that in English once we have that guidance, but I don't think
  this is the place to decide how to do that or what the implications are
  for all the other "should" statements in Policy.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #305 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Sat, 12 Apr 2014 19:46:54 +0100

Russ Allbery writes ("Bug#741573: Two menu systems"):
> So, I think the questions before the TC are:
> 
> 1. Should programs that make sense in the context of a typical DE (I
>    realize there's some fuzziness around this) all have desktop files?  If
>    so, what level of Policy requirement should that be?  (Please be more
>    specific than "should" -- maybe talk in terms of expected bug
>    severities?  For reference, I consider man pages and doc-base
>    integration to be a wishlist bug.)
> 
> 2. What level of Policy requirement is providing traditional menu files in
>    individual packages, using the same terminology?

Yes.

I think that all of these features (desktop files, trad menu entries,
manpages and doc-base bugs) should have the same status.

I would describe that status like this:

 * A maintainer should not be criticised for uploading a package
   without the feature.

 * Contributions to provide the feature are encouraged.

 * A maintainer should accept a patch which provides the feature
   (unless there is something specifically wrong with the patch).

 * In particular a maintainer should not decline such a patch on the
   grounds that they think the feature is not important or does not
   justify the effort of merging (and if necessary carring) the patch.

 * lintian ought to report the lack of the feature as a warning
   (supposed lintian can determine reasonably accurately whether the
   feature is applicable to the package).


I'm not sure that bug severity is a particularly good way of encoding
this kind of information.  Maintainers have different approaches to
bug severity and in general what a particular severity "means" (at
"normal" or below at least) is generally up to the maintainer.

Having said that I don't think "wishlist" is quite right for this.  I
think "minor" is closer.  I think that for a wishlist bug a maintainer
might reasonably decline a contributed patch on even fairly minimal
grounds.

Some maintainers leave some bugs open a long time as "wishlist
wontfix" rather than simply closing it - that provides a way, for
example, to provide information to people who newly come across the
issue.


> Things that I don't think are TC issues:
> 
> * Whether desktop files should be documented in Policy at all.  There
>   appears to be consensus that they should be, and I don't think anyone is
>   disagreeing with that consensus, so there is no dispute there.

Yes.  I think the TC resolution should explicitly state, though, as a
matter of opinion, that the TC thinks it entirely reasonable that
desktop files should be documented in policy.

> * How Policy should formally represent the distinction between different
>   levels of requirements.  I respectfully suggest that this is a question
>   of the maintenance and style of the Policy documentation, not a question
>   of technical policy for the project, and is therefore a matter for the
>   Policy Editors to decide, not the TC.  What we're looking for from the
>   TC is clear guidance on what the requirements are and what level of
>   severity those requirements have.  We clearly need to find some way to
>   represent that in English once we have that guidance, but I don't think
>   this is the place to decide how to do that or what the implications are
>   for all the other "should" statements in Policy.

I'm very happy to leave that to the policy team.  The TC resolution
should explicitly say that that's what we're doing.

Ian.

Message #310 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Anthony Towns <aj@erisian.com.au>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org

Cc: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 14 Apr 2014 02:41:54 +1000

On 12 April 2014 05:32, Russ Allbery <rra@debian.org> wrote:
> So, to take a step back, I think Ian is arguing that, by declaring the
> traditional menu system a "should," he's not introducing a problem into
> Policy that doesn't already exist, because our current use of "should" is
> all over the map.

I think it would be useful to look at this more from a "what are the
consequences if a package violates policy (and someone notices)?"

There are a bunch of possible consequences within Debian:

  - the maintainer works out a fix and uploads it
  - someone else works out a fix and files a bug
  - someone NMUs the package

  - the package gets removed from Debian by ftpmaster
  - some tool prevents the package from building/being uploaded (eg
debhelper, lintian)
  - the package doesn't get shipped in testing / stable
  - someone takes over maintenance of the package
  - it becomes okay to NMU the package without notifying the maintainer first
  - it's okay to upgrade the bug to critical/serious/important
  - it's okay to downgrade the bug to minor/wishlist
  - it's okay to close the bug without fixing it

  - someone files a bug
  - lintian/piuparts/etc reports an error

I'd divide them up into:

  - someone spends their time fixing the issue
  - bad things happen to the unfixed package
  - how likely someone is to notice

Obviously the most important/useful part of those is categories is
getting someone to fix the damn thing, but policy (and release
managers and ftpmaster et al) only really get to choose which bad
things happen as a consequence of non-compliance.

Perhaps there's another set of consequences along the lines of
"maintainer gets told off on irc, maintainer gets flamed on -devel,
maintainer gets a scolding by the tech-ctte, maintainer no longer gets
free valve games, maintainer gets kicked out of debian" that should be
considered; I don't think I'm a fan though.

> I agree with that statement as far as it goes, but I don't think it's a
> very useful observation.  Because usage of "should" is currently all over
> the map, it doesn't provide any clear guidance to the packager, which is
> what the goal should be.

"Providing guidance to the packager" sounds to me more like the first
group of advice "here's what's important, here's where you should be
spending your time to make the most effective contribution to
producing a universal free operating system". I think policy's usage
of "should" doesn't provide that sort of advice because policy's just
not designed for that.

> When working on a section of Policy, I try to fix issues like that when we
> see them.  There are various "should" requirements in Policy that I think
> are actually wishlist bugs, among them man pages and doc-base integration.

Not having a manpage has traditionally been treated as a real bug,
just not an especially high-priority one. What benefit would changing
this actually have?

I could certainly imagine, say, the DPL and others coming up with a
prioritised list of Things To Do that would make Debian way better;
but I don't think it's really policy's job to decide "oh, manpages
aren't important any more, .desktop files are where it's at".
Everything in /usr/bin should have a manpage, everything that should
show up in desktop menus should have an appropriate menu file. Not
having them is a bug, with all that entails, though not severe enough
to warrant dropping the package entirely. But that's as far as policy
should go -- Debian has lots of bugs, which ones get fixed first is an
entirely separate matter.

> 1. Should programs that make sense in the context of a typical DE (I
>    realize there's some fuzziness around this) all have desktop files?  If
>    so, what level of Policy requirement should that be?  (Please be more
>    specific than "should" -- maybe talk in terms of expected bug
>    severities?

"should" is still defined in terms of expected bug severities, isn't it?

     These classifications are roughly equivalent to the bug severities
     _serious_ (for _must_ or _required_ directive violations), _minor_,
     _normal_ or _important_ (for _should_ or _recommended_ directive
     violations) and _wishlist_ (for _optional_ items).  [2]

So I would say:

 - yes, they should
 - the consequence of not having them should be a normal severity bug
 - lack of a .desktop file shouldn't result in the package being
dropped from testing etc
 - NMU policy for adding .desktop files should be decided outside of -policy

> 2. What level of Policy requirement is providing traditional menu files in
>    individual packages, using the same terminology?

I don't see the value in the traditional menu -- from Ian's mail:

 "The trad menu is supposed to contain pretty much everything that can
be executed, [...].  Conversely, the desktop menu is supposed to
contain only a subset of programs that are considered useful for users
to find and invoke via a menu."

If the desktop menu already contains everything that's useful for
users to find and invoke via a menu, then everything additional that
the trad menu does is by definition useless (for users who want to do
menu things, anyway)... And if it's changed so it doesn't do anything
additional, what's the point?

So based on that I would say:

 - requirement that they should *not* be present
 - consequence of having them should be a minor bug

But I don't even know if I'm using desktop menus or trad menus, so...

> * How Policy should formally represent the distinction between different
>   levels of requirements.

FWIW, I think policy should be distinguishing whether its
recommendations are requirements for distribution (legal issues,
dependency errors), proper practice (ie, it's a bug if you don't do
this), or just a good idea to consider (a suggestion from experienced
developers/packagers), but beyond that should just be documenting how
to make optimal packages assuming infinite time and motivation. I
don't know how you could do that more effectively; must/should/may
still seems reasonable to me, but it doesn't seem that effective.
Splitting them as three separate documents (distro/release
requirements, policy, suggested practices) might be an option. Maybe
it would be more effective to approach the problem from the other end
-- provide a document/site of what the project thinks are the most
important things to work on, so that people who want to "force"
maintainers into doing things go there rather than debating which verb
is used in policy.

Cheers,
aj

-- 
Anthony Towns <aj@erisian.com.au>

Message #315 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Russ Allbery <rra@debian.org>

Cc: 741573@bugs.debian.org, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

Subject: Re: Bug#741573: Two menu systems

Date: Sun, 13 Apr 2014 19:38:46 -0700

Hi,

Russ Allbery wrote:

> Things that I don't think are TC issues:
>
> * Whether desktop files should be documented in Policy at all.

For what it's worth:

 * I was unhappy with the patch at http://bugs.debian.org/707851 and
   said so.  I didn't object when people seconded it and applied it
   because I didn't have a better suggestion, but I was still unhappy
   with the patch.

 * I actually suspect most people agree about the constraints and
   current status and that what's stopping us from coming up with a
   better patch to policy is that it would require either (a)
   acknowledging that the current menu policy isn't working as well as
   it should and revoking it or (b) magically providing more manpower
   to work on the menu system.

 * (a) means removing the current menu system from the normative part
   of policy.  I mean actually moving it to a new appendix or a
   sepearate document, not putting in an s/should/can/, since using
   "can" here would be very confusing in a normative document like
   policy.

   That doesn't mean killing the menu system --- it can still be
   documented, bugs filed to add menu files, etc, without
   being a normative requirement.

   I suspect not having to be wishy-washy about that would make adding
   advice in policy about the xdg menu system simpler.

 * I believe (a) is the simplest way forward.

Hope that helps,
Jonathan

Message #320 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Russ Allbery <rra@debian.org>

Cc: 741573@bugs.debian.org, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

Subject: Re: Two menu systems

Date: Mon, 14 Apr 2014 10:51:43 -0700

Hi again,

Russ Allbery wrote:

> So, I think the questions before the TC are:
>
> 1. Should programs that make sense in the context of a typical DE (I
>    realize there's some fuzziness around this) all have desktop files?

Ah, I completely misread this before as saying "menu files" instead of
"desktop files".

Was there actually any disagreement about which desktop apps should
ship desktop files?  I don't think the TC needs to answer this one if
they don't want to, except perhaps where it overlaps with the question
"What should packagers do to prevent duplicate entries when trying to
support both menu systems?"

[...]
> Things that I don't think are TC issues:
>
> * Whether desktop files should be documented in Policy at all.

I had misread this as referring to menu files, too.

Sorry for the confusion.
Jonathan

Message #325 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 741573@bugs.debian.org, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 14 Apr 2014 17:11:08 -0700

Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:

>> So, I think the questions before the TC are:
>>
>> 1. Should programs that make sense in the context of a typical DE (I
>>    realize there's some fuzziness around this) all have desktop files?

> Ah, I completely misread this before as saying "menu files" instead of
> "desktop files".

> Was there actually any disagreement about which desktop apps should ship
> desktop files?  I don't think the TC needs to answer this one if they
> don't want to, except perhaps where it overlaps with the question "What
> should packagers do to prevent duplicate entries when trying to support
> both menu systems?"

It goes to the question of whether providing desktop files are some
version of "should."  It wasn't clear to me whether we had consensus on
that part.  Bill proposed a patch that added just that part, presumably in
an attempt to test consensus on that bit, and so far I'm the only
seconder.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #330 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org

Cc: Bill Allombert <ballombe@debian.org>

Subject: Bug#741573: Please decide on a reversion of commit 3785878 in the Policy's Git repository.

Date: Mon, 5 May 2014 11:45:29 +0900

Le Thu, Apr 10, 2014 at 09:22:47AM +0900, Charles Plessy a écrit :
> Le Wed, Apr 09, 2014 at 11:34:51PM +0100, Ian Jackson a écrit :
> > 
> > It is the demotion of the traditional menu from "should" to "can"
> > which is controversial.  For the reasons I have already explained, I
> > do not agree with that.
> 
> yes, it is that part that is controversial, and I would appreciate if the TC
> would focus on it, since this was the original topic of #707851, entitled
> “soften the wording recommending menu files”. 

Dear all,

there are already 65 messages exchanged on this dicsussion (66 with this one),
not to mention the 91 messages in #707851 where, following the Policy changes
process, we reached consensus on Policy's section 9.6 on “Menus”.

The work started on May 11 2013 and ended on Feb 15 2014 with committing
changes in the Policy's Git repository.  On Feb 25 2014, Bill reverted these
changes without discussion (commit 3785878075453e6e3cac7dff8e7607905d24026f).
After failing to engage a productive negociation with Bill, on March 14 2014 I
asked to the TC to decide for us, and informed Bill and the other Policy
editors by an email on the debian-policy mailing list.

More than one month and a half later, Bill still has not explained his position
to the technical comittee.

In that context, I am asking the TC to a) acknowledge that the changes to
section 9.6 after the Policy changes process was followed accordingly, and b)
ask for Bill's commit 378587 be reverted.  In particular, in the absence of
Bill's contribution to the resolution of our conflict, I am asking the TC to
not discuss the menu systems and focus instead on correcting Bill's
misbehaviour.

What is at a stake here is not the Debian Menu system, it is the fact that in
Debian, it takes 5 minutes for one person to block one year of effort and
patience from multiple other persons.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #335 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Charles Plessy <plessy@debian.org>

Cc: 741573@bugs.debian.org, Bill Allombert <ballombe@debian.org>

Subject: Re: Bug#741573: Please decide on a reversion of commit 3785878 in the Policy's Git repository.

Date: Fri, 9 May 2014 17:08:37 -0700

Hi Charles,

Charles Plessy wrote:

>                                            In particular, in the absence of
> Bill's contribution to the resolution of our conflict, I am asking the TC to
> not discuss the menu systems and focus instead on correcting Bill's
> misbehaviour.
>
> What is at a stake here is not the Debian Menu system, it is the fact that in
> Debian, it takes 5 minutes for one person to block one year of effort and
> patience from multiple other persons.

Please take a step back, breathe, and remember that people on the policy
team probably have good intentions when doing their work.

For what it's worth, I think Bill made the right choice in reverting the
change and trying to find a variant that had consensus.  I don't think
he acted improperly.

Meanwhile I think you were acting in good faith in applying the change
in the first place.  Sometimes the presence or lack of consensus can
be hard to pin down.  But I think the menu system patch needed work,
people had said as much, and the work in setting policy in that area
wasn't done yet.

Thanks,
Jonathan

Message #340 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Nikolaus Rath <Nikolaus@rath.org>

Subject: Re: Bug#741573: Please decide on a reversion of commit 3785878 in the Policy's Git repository.

Date: Fri, 09 May 2014 21:19:14 -0700

Jonathan Nieder <jrnieder@gmail.com> writes:
> Charles Plessy wrote:
>
>>                                            In particular, in the absence of
>> Bill's contribution to the resolution of our conflict, I am asking the TC to
>> not discuss the menu systems and focus instead on correcting Bill's
>> misbehaviour.
>>
>> What is at a stake here is not the Debian Menu system, it is the fact that in
>> Debian, it takes 5 minutes for one person to block one year of effort and
>> patience from multiple other persons.
>
> Please take a step back, breathe, and remember that people on the policy
> team probably have good intentions when doing their work.

I'm pretty sure Charles knows this very well, but good intentions alone
do not justify all (in-)actions done with them. 

> For what it's worth, I think Bill made the right choice in reverting the
> change and trying to find a variant that had consensus.  I don't think
> he acted improperly.

I don't think it's worth much in the context of this bug, but since you
started it, and since I don't want Charles to become even more
frustrated because of additional, vocal after-the-fact opposition like
yours: looking through the discussion I think Bill is blocking other
people's work, and Charles is completely right in his anger. I hope the
ctte will find time for this soon.


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

Message #345 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Sun, 11 May 2014 14:57:34 -0700

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I think that all of these features (desktop files, trad menu entries,
> manpages and doc-base bugs) should have the same status.

> I would describe that status like this:

>  * A maintainer should not be criticised for uploading a package
>    without the feature.

>  * Contributions to provide the feature are encouraged.

>  * A maintainer should accept a patch which provides the feature
>    (unless there is something specifically wrong with the patch).

>  * In particular a maintainer should not decline such a patch on the
>    grounds that they think the feature is not important or does not
>    justify the effort of merging (and if necessary carring) the patch.

>  * lintian ought to report the lack of the feature as a warning
>    (supposed lintian can determine reasonably accurately whether the
>    feature is applicable to the package).

> I'm not sure that bug severity is a particularly good way of encoding
> this kind of information.  Maintainers have different approaches to
> bug severity and in general what a particular severity "means" (at
> "normal" or below at least) is generally up to the maintainer.

> Having said that I don't think "wishlist" is quite right for this.  I
> think "minor" is closer.  I think that for a wishlist bug a maintainer
> might reasonably decline a contributed patch on even fairly minimal
> grounds.

For the Lintian tag severity, minor/certain translates into a warning.
Anything less than that translates to an info (I) tag.

# Map severity/certainty levels to tag codes.
our %CODES = (
    pedantic  => { 'wild-guess' => 'P', possible => 'P', certain => 'P' },
    wishlist  => { 'wild-guess' => 'I', possible => 'I', certain => 'I' },
    minor     => { 'wild-guess' => 'I', possible => 'I', certain => 'W' },
    normal    => { 'wild-guess' => 'I', possible => 'W', certain => 'W' },
    important => { 'wild-guess' => 'W', possible => 'E', certain => 'E' },
    serious   => { 'wild-guess' => 'E', possible => 'E', certain => 'E' },
);

So if you feel like these are minor bugs (and that sounds about right to
me), they would naturally end up as warning Lintian tags provided that
Lintian can reliably detect the absence.  But that's a big caveat; see
below.

Note that your feel for the severities isn't currently what Lintian
implements.  Missing man pages are currently marked as a normal bug.  If
they were marked as minor, they would drop to an I tag, since Lintian
can't reliably determine whether a man page is present (due to man pages
provided by separate arch: all packages and a dependency).

Missing doc-base registration is currently wishlist/possible (same problem
on certainty).  I don't believe there is any Lintian diagnosis for missing
menu integration, nor (intentionally) for a missing desktop file since
it's not clear whether a given package should have a desktop file, given
the desired integration criteria.  It would be tricky to diagnose this in
Lintian, since there are a lot of binaries in /bin and /usr/bin that
should not have any sort of menu integration.  Consider pkg-config, for
example.

So... I'm a little dubious of your desire for all of this to be Lintian
warnings, since I don't think that matches Lintian's current criteria for
warnings, but I do think that the severity of the missing man page Lintian
warning may be a little overstated at the moment.  I have no idea how one
would go about writing an effective Lintian check for missing menu
integration without forcing a ridiculous and undesireable number of
overrides.

In general, I like your breakdown of expectations about maintainer
behavior.  This feels like some sort of "desired feature" level of Policy
description, which would fall between should and may.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #350 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Anthony Towns <aj@erisian.com.au>

Cc: 741573@bugs.debian.org, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

Subject: Re: Bug#741573: Two menu systems

Date: Sun, 11 May 2014 15:24:24 -0700

Anthony Towns <aj@erisian.com.au> writes:

> I'd divide them up into:
> 
>   - someone spends their time fixing the issue
>   - bad things happen to the unfixed package
>   - how likely someone is to notice

> Obviously the most important/useful part of those is categories is
> getting someone to fix the damn thing, but policy (and release managers
> and ftpmaster et al) only really get to choose which bad things happen
> as a consequence of non-compliance.

I think this is a very good way of thinking about it.

> "Providing guidance to the packager" sounds to me more like the first
> group of advice "here's what's important, here's where you should be
> spending your time to make the most effective contribution to producing
> a universal free operating system". I think policy's usage of "should"
> doesn't provide that sort of advice because policy's just not designed
> for that.

Well, but Policy *does* provide that sort of advice.  I've used it heavily
for exactly that sort of advice in the past.  One could argue that this is
really the domain of the Developers' Reference, but the distinction isn't
all that sharp.

Policy is primarily a descriptive document (here's how our integrations
function) and secondarily an aspirational document (here's what a
well-designed Debian package should look like).  It isn't really the
document that defines consequences for non-compliance, although it's
closely linked via the must directives.  That's the release criteria,
managed by the release team.  Although I suppose to some extent it defines
what bugs can't be closed without fixing them.

> Not having a manpage has traditionally been treated as a real bug, just
> not an especially high-priority one. What benefit would changing this
> actually have?

It's somewhat unrelated to this particular bug, but I think it's important
to not overstate the severity of certain problems.  Those of us who have
been working on Debian for a long time have a feel for what stuff "really
matters" and what stuff is "nice to have," but new contributors don't, and
right now the requirements are daunting and intimidating.  Ideally, the
must/should/desired language should provide a bit more of a guide to what
things are vital, what things should be worked on second, and what things
are quality of packaging issues.

In practice, we treat man pages more as a quality of packaging issue than
as part of that set of stuff you should work on second.  So I think
classing them as part of that quality of implementation group would be
doing what Policy always does: trailing and documenting project consensus.

> "should" is still defined in terms of expected bug severities, isn't it?

>      These classifications are roughly equivalent to the bug severities
>      _serious_ (for _must_ or _required_ directive violations), _minor_,
>      _normal_ or _important_ (for _should_ or _recommended_ directive
>      violations) and _wishlist_ (for _optional_ items).  [2]

> So I would say:

>  - yes, they should
>  - the consequence of not having them should be a normal severity bug
>  - lack of a .desktop file shouldn't result in the package being
> dropped from testing etc
>  - NMU policy for adding .desktop files should be decided outside of -policy

So we're converging on something in the normal to wishlist range.  :)
That's partial consensus, at least.

> I don't see the value in the traditional menu -- from Ian's mail:

>  "The trad menu is supposed to contain pretty much everything that can
> be executed, [...].  Conversely, the desktop menu is supposed to
> contain only a subset of programs that are considered useful for users
> to find and invoke via a menu."

> If the desktop menu already contains everything that's useful for
> users to find and invoke via a menu, then everything additional that
> the trad menu does is by definition useless (for users who want to do
> menu things, anyway)... And if it's changed so it doesn't do anything
> additional, what's the point?

> So based on that I would say:

>  - requirement that they should *not* be present
>  - consequence of having them should be a minor bug

> But I don't even know if I'm using desktop menus or trad menus, so...

I'm not happy with going so far as to say that they should not be present.
In general, if someone wants to maintain some piece of functionality in
Debian and feels like it's useful, we should not actively undermine that.
People may not collaborate to a degree that makes that work possible, and
they may have to be persuasive, but that's different from actively
rejecting the work.

I think the main question here is whether, from a Policy perspective,
traditional menu entries should remain in the quality of implementation
bucket or fall out of it into the "one of those things that's in Debian
but that is strictly optional" buckets.  That seems to be the root of the
disagreement.

Multiple people have stated that they like the traditional menu and care
about that integration, which is generally a good argument for keeping
something in the quality of implementation bucket.  On the other hand, I
still can't shake the feeling that the menu systems substantially
duplicate each other, and having to maintain separate configuration for
both of them feels irritating in a way that's disproportional to the
amount of work involved.  So I'm somewhat skeptical that both systems will
be maintained going forward to a sufficient degree to stay useful.

*If* we have to choose, I think the desktop menu is more useful to more of
our users.  Maybe that's just a false dichotomy and I'm borrowing trouble,
though.

> FWIW, I think policy should be distinguishing whether its
> recommendations are requirements for distribution (legal issues,
> dependency errors), proper practice (ie, it's a bug if you don't do
> this), or just a good idea to consider (a suggestion from experienced
> developers/packagers), but beyond that should just be documenting how
> to make optimal packages assuming infinite time and motivation.

That seems to roughly correspond to my categories above.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #355 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

Subject: Two menu systems

Date: Thu, 22 May 2014 15:31:59 +0100

I looked through this thread and found that I hadn't proposed anything
resembling a concrete resolution.  I would like to do that now:

  Context

  1. A dispute about the status of menu systems in Debian, and the
     contents of policy, has been referred to the Committee.

  2. There are currently two menu systems in Debian: the
     freedesktop.org (.desktop file based) system, and the traditional
     Debian menu system.

  3. These two systems have, in general: different maintainers and
     proponents; often different users; different intended scopes (in
     the sense of what subset of packages in Debian should provide
     menu entries); a different emphasis.

  4. The two systems make different choices in response to the need
     for various technical tradeoffs.  The traditional Debian menu is
     less feature rich, but is easier for a menu consumer.

  Philosophy

  5. Where feasible, there should be room in Debian for competing
     implementations of similar functionality; especially when they
     have different but overlapping sets of goals.  The contributors
     to each should be enabled to do their work, so long as the cost
     for the project as a whole is reasonable.

  Conclusions

  6. Both menu systems should be documented in policy.

  7. The documentation for each menu system (specifying file formats,
     when to include a menu entry, etc.) should follow the views of
     Debian's experts on, and contributors to, each system.

  8. Lack of an entry in one or other menu system, where that system's
     scope calls for an entry to be provided, is a bug.  But it is not
     a release critical bug.

  9. A maintainer should not be criticised for providing a package
     without doing the work to provide all the applicable menu
     entries.  However, a maintainer who is offered a reasonable patch
     should accept it.

  10. We request that the policy team implement this decision.  We
     leave the specific details of the wording to the policy team.

Ian.

Message #360 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 26 Jun 2014 17:50:38 +0100

I see Keith has committed a draft to git.  As discussed, I disagree
with this approach.  This amounts to nonconsensually abolishing
someone's work when it is still being maintained, and the global cost
is minimal.

But I'd like to make some specific comments too.  (I'm reading
24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a
copy.)

Firstly, there is no talk of a transition plan.  There is AIUI
currently a mixture of programs which provide both kinds of entry and
programs which provide only one or only the other.  A resolution
saying that these things should be unified needs to either contain the
transition plan, or say that someone (who?) should write it.  If the
transition plan is to be written later, the resolution should also say
what should happen in the meantime.

Secondly, it doesn't discuss how these menus will be organised or
displayed.  In particular, it doesn't discuss how to manage the
distinction between:
  - Menu consumers who want to display a comprehensive menu along
    the lines of the traditional Debian menu;
  - Menu consumers who want to display a curated or filtered menu
    along the lines of the desktop system menus.
And, of course, the corresponding distinction between the different
kinds of program.

At the very least the resolution needs to acknowledge that these
distinctions exist and say that they are not being abolished.  Or, if
they are, say which of the two uses is being abolished.

Thirdly, IMO the resolution needs to acknowledge (in the "whereas"
section) that consuming a trad Debian menu entry is simpler and easier
than consuming a .desktop file.

Thanks,
Ian.


--- Keith's proposal:

 Whereas:

   1. The Debian Policy Manual states (§9.6) that 'The Debian menu
      package provides a standard interface between packages providing
      applications and "menu programs"'. It further states that 'All
      packages that provide applications that need not be passed any
      special command line arguments for normal operations should
      register a menu entry for those applications'.

   2. All details about menu system requirement are delegated to the
      Debian Menu sub-policy and Debian Menu System manuals (the
      "Debian menu system").

   3. An external specification, the Freedesktop Desktop Entry
      Specification (the ".desktop spec"), with native support in many
      X desktop environments, has appeared since the Debian Menu
      system was developed. The .desktop spec offers a fairly strict
      super-set of Debian Menu system functionality.

   4. The .desktop specification has significant technical benefits
      for users over the Debian menu system. The .desktop
      specification works together with the freedesktop.org mime type
      and icon specifications to provide operations expected by
      desktop users from other environments, such as Mac OS X or
      Windows. As such, applications must provide a .desktop file to
      operate well in most desktop environments.
       
   5. The Debian Technical Committee has been asked to resolve a
      dispute between maintainers of Debian Policy over a change that

      i. incorporates the description of the FreeDesktop menu system
         and its use in Debian for listing program in desktop menus
         and associating them with media types

     ii. softens the wording on the Debian Menu system to reflect that
         in Jessie it will be neither displayed nor installed by
         default on standard Debian installations.

 Therefore:   

   1. The Technical Committee resolves that packages for which the
      Debian menu system currently applies should provide a .desktop
      file. Applications providing a .desktop file should not
      provide a Debian menu file.

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

   3. We recommend that the maintainers of the 'menu' package update
      that package to reflect this increased focus on .desktop files
      by modifying the 'menu' package to use .desktop files for the
      source of menu information in addition to menu files.

   4. Discussion of the precise relationship between menu file
      section/hints values and .desktop file Categories values may be
      defined within the Debian Menu sub-policy and Debian Menu
      System.

The following information is an informative addition to help describe
the motivation for this policy change.

   A. The .desktop spec provides more functionality:

	a) Associating mime types with applications
	b) Support for more icon image formats
	c) Translation of menu items
	d) D-Bus application activation
	e) StartupNotify support


   B. Support for the .desktop spec is widely provided as part of
      upstream packaging for desktop applications.


   C. A .desktop file describe in the .desktop spec captures
      essentially all of the information present in the Debian menu
      system:

      menu	.desktop		Notes
      ?package	TryExec			[0]
      title	Name / GenericName	[1]
      needs	Terminal		[2]
      section   Catagories		[3]
      command	Exec
      icon	Icon			[4]
      hints	Catagories		[5]

      Notes

      [0] ?package uses Debian package names, TryExec offers a
          system-independent mechanism using a special program or
	  mode of the existing program to query whether the
          dependencies to run the application are satisfied

      [1] GenericName can offer a brief functional description of a
          program, much like the Debian alternatives for things like
          www-browser

      [2] needs adds 'vc' and 'wm' classifications, a .desktop file
          does not anticipate running applications on virtual consoles
          as a separate notion from within an X. I'll note that the
	  only package on my system with needs="vc" is psmisc for the
          pstree application, which runs just fine in any X terminal
          emulator. Also .desktop files do not expect people to switch
          window managers during a session.

      [3] The menu file requires that the package define the entire
          menu path to the entry, while the .desktop file defines only
	  the Catagories within the menu, which allows the user
          environment to construct its own presentation method

      [4] Menu files allow only for xpm format icons while
          .desktop files support a wide variety of image formats,
          including png jpg and svg. Menu files also limit the size of
          icons to 32x32, which can be painfully small on higher
          resolution monitors, or less detailed when scaled to large
          sizes.

      [5] Because the .desktop specification does not enforce a
          particular layout of menu entries, applications are
          encouraged to specify as many 'categories' as they like and
          have the menu system pick where to include them. This can
          easily include policies like that described for the hints
          field in the Debian menu.

    D. .desktop files also provide additional fields not present in
       the Debian menu system:

       Type		Application, Link or Directory. The latter two
			provide a common format for storing references
			to non-application objects within the desktop
			environment.

       NoDisplay	An artifact of the ability to handle
		        content-based application launching; a
		        NoDisplay entry isn't shown in the menu
		        system, but is available for handling Mime types.

       Comment		Offered as a tooltip to the user, providing
			additional details about the application.

       Hidden		An artifact of the implementation allowing
			users to selectively disable system menu entries

       OnlyShowIn/	Allows desktop-system specific applications to not
       NotShowIn	appear in other desktop environments, such as
			desktop system preferences systems.

       DBusActivatable	Whether the application supports standard
		        D-Bus messages to control the application, including
			the ability to direct applications to open
		        additional files or perform other operations

       Path	        The starting directory for the application. I
			haven't found any .desktop file using this
			feature, but it is replicates functionality
			present in Mac OSX and Windows.

       Actions		Similar to a mechanism provided on Windows
			where you can list many different operations
			available from a single application, such as
			"open", "print", "play", "frobnicate" and
			Windows automatically adds these to the
			right-click menu from within explorer.

       MimeType		The mime types supported by the
			application. This allows the wider system to
			find a application suitable for
			viewing/modifying specific content, such as a
			file browser.
       
       KeyWords		Provides tags to allow for some degree of
		        search-ability/categorization of menu
		        entries. I'd be able to explain this in more
		        detail if I could find any examples of it in use.

       StartupNotify/	Announces that the application supports the Startup
       StartupWMClass	Notification Protocol Specification, which
			allows the desktop environment to detect when
			the application has successfully launched so
			that it can disable the waiting cursor.

       URL		Used in 'Link' .desktop files to reference an object.

    E. .desktop files cede significant authority over menu
       organization to the user agent presenting the overall
       application menu. This is already a reality as many desktop
       environments show *none* of the menu file data at all; having
       applications which currently ship a menu file change to
       shipping a .desktop file will bring them into uniformity with
       other pieces of the desktop environment by incorporating them
       into the existing desktop menu system

    F. The .desktop specification and other Freedesktop.org
       specifications relating to mime types and icons are all interrelated
       and work together to provide a system capable of implementing
       common desktop operations. Not providing a .desktop file
       significantly reduces the functionality of the overall
       environment, and 
       

Message #365 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 26 Jun 2014 17:54:10 +0100

Ian Jackson writes ("Re: Bug#741573: Two menu systems"):
> But I'd like to make some specific comments too.  (I'm reading
> 24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a
> copy.)
...

Oh, and:

Fourthly: It makes no provision for the translation into the new
regime of the carefully curated organisational structure of the
existing Debian menus.  Without such a translation it amounts to
throwing away a lot of work.

Ian.

Message #370 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 26 Jun 2014 18:31:54 +0100

On Thu, Jun 26, 2014 at 05:50:38PM +0100, Ian Jackson wrote:
> I see Keith has committed a draft to git.  As discussed, I disagree
> with this approach.  This amounts to nonconsensually abolishing
> someone's work when it is still being maintained, and the global cost
> is minimal.

My feelings on this draft are mixed.

On the one hand, I happen to agree with the position that the
categorisation system in .desktop files (and X-Show-In etc.) should be
able to cover the bulk of the practical requirements of the trad menu
system:

 * There's no reason that "has a .desktop file" should imply "shows up
   in modern desktop environments", and so I think that the question of
   coverage is to some extent a red herring; the systems have different
   coverage because they've always had different coverage, not because
   the .desktop format is inherently unable to meet the needs of trad
   menu consumers.

 * We might have to look into the presentation of menu item names,
   although Name / GenericName offers some support for the different
   names that people are likely to want, and if all else fails the
   .desktop file format does have extension mechanisms.

I would be very happy to see additional .desktop files being added to
packages with suitable categorisation such that they don't need to
interfere with how the maintainers of modern DEs want to present their
desktops, so that menu-xdg (or similar) can supplant the current menu
system with negligible loss of functionality for users of trad menus.  I
think this would make a great project for people interested in unifying
the two worlds a bit more, which doesn't even have to step on anyone's
toes.  Perhaps for instance it would be a good project for Debian's
Google Summer of Code efforts.

On the other hand, Keith's draft seems highly aspirational to me.  While
it seems to me to be broadly the right kind of long-term technical
direction, there is an awful lot of work in there for people who want
something like trad menus which is being glossed over.


So, I prefer Ian's position in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the
purposes of how the policy text should remain for the time being, and in
terms of the philosophy of not ripping out work from under people's
feet.  I disagree with its argument that it follows directly from the
two sets of competing requirements that we must have these two file
formats.  I prefer Keith's position as a long-term direction, but agree
with Ian that it is lacking an awful lot of transitional thought, and
feel that it has a lot of things-should-be-done without it being clear
who will do them.

> Thirdly, IMO the resolution needs to acknowledge (in the "whereas"
> section) that consuming a trad Debian menu entry is simpler and easier
> than consuming a .desktop file.

I think this is really overstated.  .desktop files are in a
long-standing and popular basic file format for which plenty of parsing
libraries in various languages exist, so you can get to the point of
having a parsed data structure trivially.  In contrast the menu entry
format is a bespoke thing.  While the .desktop file format has more
bells and whistles, many of them can be ignored if you don't support
whatever it is.  I don't think it's worth emphasising ease of
consumption either way.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #375 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Colin Watson <cjwatson@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Thu, 26 Jun 2014 11:08:54 -0700

(Sorry I missed the meeting today.  I'm away on vacation and my schedule
ended up not aligning properly.)

Colin Watson <cjwatson@debian.org> writes:

> I think this is really overstated.  .desktop files are in a
> long-standing and popular basic file format for which plenty of parsing
> libraries in various languages exist, so you can get to the point of
> having a parsed data structure trivially.  In contrast the menu entry
> format is a bespoke thing.  While the .desktop file format has more
> bells and whistles, many of them can be ignored if you don't support
> whatever it is.  I don't think it's worth emphasising ease of
> consumption either way.

The counterpoint here, which I had missed earlier in this discussion, is
the file format for the menus themselves, not the *.desktop files.  I
agree with you about the *.desktop file format, but the specification for
the menus is much more complicated.  See:

    http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

I'm not positive that the syntax of /etc/menu-methods is any less complex,
but it's at least arguable, and it's certainly way different and already
designed for generating menus for other applications that don't inherently
support the XDG menu system.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #380 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Cameron Norman <camerontnorman@gmail.com>

To: Colin Watson <cjwatson@debian.org>, "741573@bugs.debian.org" <741573@bugs.debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 27 Jun 2014 04:59:50 -0700

[Message part 1 (text/plain, inline)]

On Thursday, June 26, 2014, Colin Watson <cjwatson@debian.org> wrote:

> On Thu, Jun 26, 2014 at 05:50:38PM +0100, Ian Jackson wrote:
> > I see Keith has committed a draft to git.  As discussed, I disagree
> > with this approach.  This amounts to nonconsensually abolishing
> > someone's work when it is still being maintained, and the global cost
> > is minimal.
>
> My feelings on this draft are mixed.
>
> On the one hand, I happen to agree with the position that the
> categorisation system in .desktop files (and X-Show-In etc.) should be
> able to cover the bulk of the practical requirements of the trad menu
> system:
>
>  * There's no reason that "has a .desktop file" should imply "shows up
>    in modern desktop environments", and so I think that the question of
>    coverage is to some extent a red herring; the systems have different
>    coverage because they've always had different coverage, not because
>    the .desktop format is inherently unable to meet the needs of trad
>    menu consumers.
>
>  * We might have to look into the presentation of menu item names,
>    although Name / GenericName offers some support for the different
>    names that people are likely to want, and if all else fails the
>    .desktop file format does have extension mechanisms.
>
> I would be very happy to see additional .desktop files being added to
> packages with suitable categorisation such that they don't need to
> interfere with how the maintainers of modern DEs want to present their
> desktops, so that menu-xdg (or similar) can supplant the current menu
> system with negligible loss of functionality for users of trad menus.  I
> think this would make a great project for people interested in unifying
> the two worlds a bit more, which doesn't even have to step on anyone's
> toes.  Perhaps for instance it would be a good project for Debian's
> Google Summer of Code efforts.
>
> On the other hand, Keith's draft seems highly aspirational to me.  While
> it seems to me to be broadly the right kind of long-term technical
> direction, there is an awful lot of work in there for people who want
> something like trad menus which is being glossed over.
>
>
> So, I prefer Ian's position in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the
> purposes of how the policy text should remain for the time being, and in
> terms of the philosophy of not ripping out work from under people's
> feet.  I disagree with its argument that it follows directly from the
> two sets of competing requirements that we must have these two file
> formats.  I prefer Keith's position as a long-term direction, but agree
> with Ian that it is lacking an awful lot of transitional thought, and
> feel that it has a lot of things-should-be-done without it being clear
> who will do them.
>
> > Thirdly, IMO the resolution needs to acknowledge (in the "whereas"
> > section) that consuming a trad Debian menu entry is simpler and easier
> > than consuming a .desktop file.
>
> I think this is really overstated.  .desktop files are in a
> long-standing and popular basic file format for which plenty of parsing
> libraries in various languages exist, so you can get to the point of
> having a parsed data structure trivially.  In contrast the menu entry
> format is a bespoke thing.  While the .desktop file format has more
> bells and whistles, many of them can be ignored if you don't support
> whatever it is.  I don't think it's worth emphasising ease of
> consumption either way.


I believe the major aspect of .desktop files that makes them harder is the
icon handling. Perhaps debian policy should instruct that a certain icon
size must always be available in a particular format (e.g. 32x32 png) so
that WMs do not have to handle so many corner cases in that area.

Best,
--
Cameron Norman

[Message part 2 (text/html, inline)]

Message #385 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: Cameron Norman <camerontnorman@gmail.com>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Sun, 29 Jun 2014 10:30:58 +0900

Le Fri, Jun 27, 2014 at 04:59:50AM -0700, Cameron Norman a écrit :
> 
> I believe the major aspect of .desktop files that makes them harder is the
> icon handling. Perhaps debian policy should instruct that a certain icon
> size must always be available in a particular format (e.g. 32x32 png) so
> that WMs do not have to handle so many corner cases in that area.

Hi Cameron,

When working on #707851, I made sure that this is addressed with the input of
Debian maintainers of desktop environments using the FreeDesktop menu.

http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=ba679bff76f5b9152f43d5bc901b9b3aad257479;hp=f6997b3ba7
93c9a9e463cca9f7e7b138add8b788   

Here is the relevant extract.

+         Entries displayed in the FreeDesktop menu should conform to the
+         following minima for relevance and visual integration.
+
+         <list>
+           <item>
+             Unless hidden by default, the desktop entry must point to a PNG
+             or SVG icon with a transparent background, providing at least
+             the 22&times;22 size, and preferably up to 64&times;64.  The icon
+             should be neutral enough to integrate well with the default icon
+             themes.  It is encouraged to ship the icon in the default
+             <em>hicolor</em> icon theme directories, or to use an existing
+             icon from the <em>hicolor</em> theme.
+           </item>
+
+           <item>
+             If the menu entry is not useful in the general case as a
+             standalone application, the desktop entry should set the
+             <tt>NoDisplay</tt> key to <var>true</var>, so that it can be
+             configured to be displayed only by those who need it.
+           </item>
+
+           <item>
+             In doubt, the package maintainer should coordinate with the
+             maintainers of menu implementations through the
+             <em>debian-desktop</em> 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 <tt>NotShowIn</tt>/<tt>OnlyShowIn</tt> keys should be
+             validated by the maintainers of the relevant environments.
+           </item>
+         </list>


I beleive that this part is non-controversial.  The controversy is whether we
should still require with the strenght of a "should" in the Policy that
packages have to contain a Debian Menu entry, ignoring the fact that a) a lot
of packages have already not respected this point for years, if not decades,
and b) the Debian Menu is not anymore part of standard installations in Jessie.

That is: this part of the patch (reformatted by hand for easier reading).

        <p>
-         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 <tt>menu</tt> package
-         will automatically get menu entries in their window
-         managers, as well in shells like <tt>pdmenu</tt>.
        </p>

        <p>
-         The menu policy can be found in the <tt>menu-policy</tt>
-         files in the <tt>debian-policy</tt> package.
-         It is also available from the Debian web mirrors at
-          <tt><url name="/doc/packaging-manuals/menu-policy/"
-               id="http://www.debian.org/doc/packaging-manuals/menu-policy/"></tt>.
        </p>
 
-       <p>
-         Please also refer to the <em>Debian Menu System</em>
-         documentation that comes with the <package>menu</package>
-         package for information about how to register your
-         applications.
+        <p>
+         Packages can, to be compatible with Debian additions to some window
+         managers that do not support the FreeDesktop standard, also provide a
+         <em>Debian menu</em> file, following the <em>Debian menu policy</em>,
+         which can be found in the <tt>menu-policy</tt> files in the
+         <tt>debian-policy</tt> package.  It is also available from the Debian
+         web mirrors at <tt><url name="/doc/packaging-manuals/menu-policy/"
+         id="http://www.debian.org/doc/packaging-manuals/menu-policy/"></tt>.
        </p>

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #390 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 14:00:52 -0700

[Message part 1 (text/plain, inline)]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Ian Jackson writes ("Re: Bug#741573: Two menu systems"):
>> But I'd like to make some specific comments too.  (I'm reading
>> 24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a
>> copy.)
> ...
>
> Oh, and:
>
> Fourthly: It makes no provision for the translation into the new
> regime of the carefully curated organisational structure of the
> existing Debian menus.  Without such a translation it amounts to
> throwing away a lot of work.

I tried to cover this here:

    4. Discussion of the precise relationship between menu file
       section/hints values and .desktop file Categories values may be
       defined within the Debian Menu sub-policy and Debian Menu
       System.

I could include a strawman translation between these two sets as a part
of this proposal if you think that would help.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #395 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 13:59:00 -0700

[Message part 1 (text/plain, inline)]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I see Keith has committed a draft to git.  As discussed, I disagree
> with this approach.  This amounts to nonconsensually abolishing
> someone's work when it is still being maintained, and the global cost
> is minimal.

Right, as I said in the May TC meeting, I would draft a proposal that
provided an option which was .desktop-focused. It's not complete yet;
several people have graciously pointed out some fairly obvious bugs.

One of the arguments that I had heard expressed against supporting
applications shipping .desktop files is that it would reduce the number
of applications offered in existing menu packages; I'm hoping that my
draft addresses this question by demonstrating that the .desktop format
offers a proper superset of the information found in menu files, and
that package maintainers could mechanically convert their existing menu
files into .desktop files without loss of information.

> Firstly, there is no talk of a transition plan.  There is AIUI
> currently a mixture of programs which provide both kinds of entry and
> programs which provide only one or only the other.  A resolution
> saying that these things should be unified needs to either contain the
> transition plan, or say that someone (who?) should write it.  If the
> transition plan is to be written later, the resolution should also say
> what should happen in the meantime.

I'm afraid that my notion of a transition plan was expressed implicitly
in the proposal rather than explicitly. In any case, the transition plan
I had in mind was pretty simple:

 1. Implement .desktop parsing support in the existing 'menu' package so
    that packages providing only .desktop files would be incorporated
    into menu programs without further change.

 2. Transition packages from providing menu files to providing .desktop
    files, deprecating support for the menu file format within the
    archive over time.

These goals were both expressed in terms of 'should' statements in the
proposal, all of which were to be read in standard terms indicating that
failing to follow these policies would be considered a bug.

It sounds like you'd like to see this transition written in a clearer
and more concrete fashion though.

> Secondly, it doesn't discuss how these menus will be organised or
> displayed.  In particular, it doesn't discuss how to manage the
> distinction between:
>   - Menu consumers who want to display a comprehensive menu along
>     the lines of the traditional Debian menu;
>   - Menu consumers who want to display a curated or filtered menu
>     along the lines of the desktop system menus.
> And, of course, the corresponding distinction between the different
> kinds of program.

Right now, the problem we have is that many common menu programs display
only applications which install .desktop files. I don't think that's a
result of careful curating by the menu programs, but rather that the
menu programs end up choosing between the two menu systems, and are often
selecting the one preferred by the upstream menu program developers.

I'd love to see so many programs in my menu that menu program developers
are encouraged to figure out how to reasonably select entries in menus
so that we can get to some kind of intentional preferential listing
mechanism, rather than the ad-hoc selection that we have today.

However, I don't think that Policy is a sound place to make user
interface design decisions, and that we should naturally defer how to
present the provided application set to the menu program developers. I
believe this part of Policy should focus on stating what application
developers are expected to provide for the menu system, and then let the
menu program do 'something sensible' with the provided data.

The freedesktop.org specifications offer some guidance in this area, but
the wide range of potential user interface implementations for
application selection leaves them without a lot of explicit detail.

> At the very least the resolution needs to acknowledge that these
> distinctions exist and say that they are not being abolished.  Or, if
> they are, say which of the two uses is being abolished.

I think this distinction is entirely an artifact of the current split
between packages, some of which install only a menu file, and some of
which install both menu and .desktop files. I would hope that by
encouraging all packages to deliver only .desktop files, we'll see
developers thinking about sensible ways to present hundreds of
applications to their users.

What I'm hearing you say is that you'd like to ensure that users
continue to have an option of seeing all of the programs they've
installed available in a menu system. I'm emphatically agreeing with you
here, to the point where I'm proposing that we make it normal for *all*
menu programs to present all of the installed programs in their menus,
and then encouraging them to figure out how to display them in a
sensible and efficient manner.

> Thirdly, IMO the resolution needs to acknowledge (in the "whereas"
> section) that consuming a trad Debian menu entry is simpler and easier
> than consuming a .desktop file.

I would dispute this statement; there are C, perl and python library
bindings for the entire suite of freedesktop.org specifications which
make dealing with these file formats straightforward. As the standards are
cross-distribution systems, support and knowledge are far broader than
any Debian-specific system.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #400 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Colin Watson <cjwatson@debian.org>, 741573@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 14:33:14 -0700

[Message part 1 (text/plain, inline)]

Colin Watson <cjwatson@debian.org> writes:

>  * There's no reason that "has a .desktop file" should imply "shows up
>    in modern desktop environments", and so I think that the question of
>    coverage is to some extent a red herring; the systems have different
>    coverage because they've always had different coverage, not because
>    the .desktop format is inherently unable to meet the needs of trad
>    menu consumers.

That's my view -- the two systems are split because they use a different
file format, and not through any carefully considered reason.

> On the other hand, Keith's draft seems highly aspirational to me.  While
> it seems to me to be broadly the right kind of long-term technical
> direction, there is an awful lot of work in there for people who want
> something like trad menus which is being glossed over.

I think the only piece of work necessary is to add support for .desktop
files to the 'menu' package. With that, other packages are free to
transition from menu files to .desktop files and any existing menu
programs will continue to work as before, while .desktop file consuming
menu programs will slowly see more and more applications to present.

> So, I prefer Ian's position in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the
> purposes of how the policy text should remain for the time being, and in
> terms of the philosophy of not ripping out work from under people's
> feet.

I guess I'm not sure what work we're ripping out from under people's
feet here. The only significant change proposed is to require support
for .desktop files in the 'menu' package. I would imagine that the
simplest way to add .desktop file support to the 'menu' package would be
to translate .desktop files into menu files and process those through
the existing code base.

> I prefer Keith's position as a long-term direction, but agree
> with Ian that it is lacking an awful lot of transitional thought, and
> feel that it has a lot of things-should-be-done without it being clear
> who will do them.

I feel like there's a mis-characterization of what it would mean to
switch to .desktop files, and whether the change would need to be
all-at-once or could be done incrementally. Here's the transition that I
imagine would occur:

 1) Support for .desktop files is added to the 'menu' package. This
    ensures that applications providing only a .desktop file would
    continue to appear in menu programs using the existing menu package
    infrastructure.

 2) Packages would be encouraged to transition to shipping only .desktop
    files. Over time, more and more would start to appear in menu
    programs with native .desktop support.

 3) .desktop-based menu program users would start exploring the broader
    range of applications shown to them and enjoy the benefits of this
    broader selection of tools.

None of these steps places any specific burden on developers, although
skipping step 1) would regress menu programs using menu package support,
dropping any programs which choose to not ship a menu file. I would
expect that to be sufficient incentive for the 'menu' package to add
.desktop file support though.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #405 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 23:36:57 +0200

Hi,

Le lundi 30 juin 2014 à 13:59 -0700, Keith Packard a écrit : 
> One of the arguments that I had heard expressed against supporting
> applications shipping .desktop files is that it would reduce the number
> of applications offered in existing menu packages; I'm hoping that my
> draft addresses this question by demonstrating that the .desktop format
> offers a proper superset of the information found in menu files, and
> that package maintainers could mechanically convert their existing menu
> files into .desktop files without loss of information.

One of the problems I have with your proposal, compared to Charles’
original patch, is that it encourages maintainers of hundreds of (IMHO
useless) menu files to port them to the desktop format.

We don’t need menu entries for bc or python, unless they are
NoDisplay=true. This should be obvious, but currently we have trad menu
entries for them. The proposed wording for the policy (which is the
result of a compromise work between desktop maintainers and policy
editors) handles this by stating maintainers must set appropriate
NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
are not cooperative in this matter (hence gross hacks such as
gnome-menus-blacklist).

> I'm afraid that my notion of a transition plan was expressed implicitly
> in the proposal rather than explicitly. In any case, the transition plan
> I had in mind was pretty simple:
> 
>  1. Implement .desktop parsing support in the existing 'menu' package so
>     that packages providing only .desktop files would be incorporated
>     into menu programs without further change.

That part of the plan is obvious: replace the current “menu” package by
https://wiki.archlinux.org/index.php/Xdg-menu

>  2. Transition packages from providing menu files to providing .desktop
>     files, deprecating support for the menu file format within the
>     archive over time.
[snip] 
> I'd love to see so many programs in my menu that menu program developers
> are encouraged to figure out how to reasonably select entries in menus
> so that we can get to some kind of intentional preferential listing
> mechanism, rather than the ad-hoc selection that we have today.

Experience shows it doesn’t work. You can have ad-hoc selection after
time (either automatic or manual), but you need something that works out
of the box. Three-level nested menus with hundreds of entries are not
something to present a new user, regardless of her proficiency.

> However, I don't think that Policy is a sound place to make user
> interface design decisions, and that we should naturally defer how to
> present the provided application set to the menu program developers. I
> believe this part of Policy should focus on stating what application
> developers are expected to provide for the menu system, and then let the
> menu program do 'something sensible' with the provided data.

Agreed.

[snip] 
> I think this distinction is entirely an artifact of the current split
> between packages, some of which install only a menu file, and some of
> which install both menu and .desktop files. I would hope that by
> encouraging all packages to deliver only .desktop files, we'll see
> developers thinking about sensible ways to present hundreds of
> applications to their users.

There is a sensible way: not present the useless ones. Use
NoDisplay=true everywhere appropriate.

I don’t think presenting the whole contents of /usr/bin in a menu is
helpful in any way to anyone.

Cheers,
-- 
 .''`.        Josselin Mouette
: :' :
`. `'
  `-

Message #410 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Cameron Norman <camerontnorman@gmail.com>, 741573@bugs.debian.org, Colin Watson <cjwatson@debian.org>, "741573\@bugs.debian.org" <741573@bugs.debian.org>

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 16:01:36 -0700

[Message part 1 (text/plain, inline)]

Cameron Norman <camerontnorman@gmail.com> writes:

> I believe the major aspect of .desktop files that makes them harder is the
> icon handling. Perhaps debian policy should instruct that a certain icon
> size must always be available in a particular format (e.g. 32x32 png) so
> that WMs do not have to handle so many corner cases in that area.

A window manager will need to handle resizing of icons in any case, and
it's pretty darn hard to pin down which sizes to require when so many
screen sizes and resolutions are in common use these days. Ideally, the
icon artwork is presumably coming from upstream and not constructed for
packaging purposes; that will naturally limit the icons to what is
provided, making mandating specific sizes somewhat impractical.

Of course, I would encourage application developers to provide .svg
icons instead of fixed sizes. That gives the window manager the
ability to present something good looking at any size.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #415 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org, Colin Watson <cjwatson@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 16:19:58 -0700

[Message part 1 (text/plain, inline)]

Russ Allbery <rra@debian.org> writes:

> The counterpoint here, which I had missed earlier in this discussion, is
> the file format for the menus themselves, not the *.desktop files.  I
> agree with you about the *.desktop file format, but the specification for
> the menus is much more complicated.  See:
>
>     http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

I didn't actually review that spec before putting together my
draft. I think it's slightly orthogonal to the question of how
applications publish information about themselves to a menu program
though.

> I'm not positive that the syntax of /etc/menu-methods is any less complex,
> but it's at least arguable, and it's certainly way different and already
> designed for generating menus for other applications that don't inherently
> support the XDG menu system.

It seems to me that the freedesktop .menu file format is that can be
mechanically constructed from the set of installed .desktop files, at
least by default. To some degree, that makes it something of an
implementation detail for a particular menu program. I think it is
documented so that external menu editing tools can be written to
rearrange things from the default configuration.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #420 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Josselin Mouette <joss@debian.org>, 741573@bugs.debian.org, 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 16:35:32 -0700

[Message part 1 (text/plain, inline)]

Josselin Mouette <joss@debian.org> writes:

> One of the problems I have with your proposal, compared to Charles’
> original patch, is that it encourages maintainers of hundreds of (IMHO
> useless) menu files to port them to the desktop format.

Yeah, there are a lot of inappropriate entries in my /usr/share/menu
directory. Can we fix policy to weed these out? The current
wording in §9.6:

      All packages that provide applications that need not be passed any
      special command line arguments for normal operations should
      register a menu entry for those applications.

seems problematic to me -- it seems to require menu entries for things
as diverse as a web browser and a python interpreter. Coming up with
wording that encourages only programs which are conventionally used in
interactive mode to be included seems like a good fix here.

> We don’t need menu entries for bc or python, unless they are
> NoDisplay=true. This should be obvious, but currently we have trad menu
> entries for them. The proposed wording for the policy (which is the
> result of a compromise work between desktop maintainers and policy
> editors) handles this by stating maintainers must set appropriate
> NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
> are not cooperative in this matter (hence gross hacks such as
> gnome-menus-blacklist).

I think it's a lack of clarity in the spec which encourages
over-production of menu entries.

> Experience shows it doesn’t work. You can have ad-hoc selection after
> time (either automatic or manual), but you need something that works out
> of the box. Three-level nested menus with hundreds of entries are not
> something to present a new user, regardless of her proficiency.

I completely agree, but I don't think we can mandate good UI design in
Policy, all we can do is provide the tools necessary to construct a good
UI.

> There is a sensible way: not present the useless ones. Use
> NoDisplay=true everywhere appropriate.
>
> I don’t think presenting the whole contents of /usr/bin in a menu is
> helpful in any way to anyone.

As you say, we can't expect package developers to always make the
choices we'd like. I don't have any good solutions here, but I don't
think how the underlying menu information is transmitted in the package
is affected by that problem.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #425 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Nikolaus Rath <Nikolaus@rath.org>

To: Keith Packard <keithp@keithp.com>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 21:22:28 -0700

Keith Packard <keithp@keithp.com> writes:
>  1. Implement .desktop parsing support in the existing 'menu' package so
>     that packages providing only .desktop files would be incorporated
>     into menu programs without further change.


FWIW, it seems there is at least partial support for that already. At
least on my testing system, there is:

NAME
       desktop2menu - create a menu file skeleton from a desktop file

SYNOPSIS
       desktop2menu --help|--version

       desktop2menu desktop file [package name]

DESCRIPTION
       desktop2menu generates a skeleton menu file from the supplied
       freedesktop.org desktop file.

       The package name to be used in the menu file may be passed as an
       additional argument. If it is not supplied then desktop2menu will
       attempt to derive the package name from the data in the desktop file.

LICENSE
       This program is Copyright (C) 2007 by Sune Vuorela
       <debian@pusling.com>. It was modified by Adam D. Barratt
       <adam@adam-barratt.org.uk> for the devscripts package.  This program
       comes with ABSOLUTELY NO WARRANTY.  You are free to redistribute this
       code under the terms of the GNU General Public License, version 2 or
       later.

AUTHOR
       Sune Vuorela <debian@pusling.com> with modifications by Adam D. Barratt
       <adam@adam-barratt.org.uk>

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

Message #430 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Nikolaus Rath <Nikolaus@rath.org>, 741573@bugs.debian.org

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 22:25:41 -0700

[Message part 1 (text/plain, inline)]

Nikolaus Rath <Nikolaus@rath.org> writes:

> Keith Packard <keithp@keithp.com> writes:
>>  1. Implement .desktop parsing support in the existing 'menu' package so
>>     that packages providing only .desktop files would be incorporated
>>     into menu programs without further change.
>
>
> FWIW, it seems there is at least partial support for that already. At
> least on my testing system, there is:
>
> NAME
>        desktop2menu - create a menu file skeleton from a desktop file

Thanks for pointing that out. desktop2menu is a perl script which uses
the published perl bindings for .desktop files and has a start at a
mapping from .desktop Categories to menu sections. It also doesn't
correctly handle generating .xpm files for the icons.

I think this does demonstrate that we could, with little effort, allow
applications to ship only .desktop files and have the menu package take
those and generate menu files for other systems.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #435 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Keith Packard <keithp@keithp.com>

Cc: 741573@bugs.debian.org, Nikolaus Rath <Nikolaus@rath.org>

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 30 Jun 2014 23:23:53 -0700

Keith Packard <keithp@keithp.com> writes:

> Thanks for pointing that out. desktop2menu is a perl script which uses
> the published perl bindings for .desktop files and has a start at a
> mapping from .desktop Categories to menu sections. It also doesn't
> correctly handle generating .xpm files for the icons.

> I think this does demonstrate that we could, with little effort, allow
> applications to ship only .desktop files and have the menu package take
> those and generate menu files for other systems.

Isn't this the tool that Sune wrote and mentioned earlier in this bug as
being incomplete and primarily useful for generating a template that
requires subsequent work?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#45

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #440 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@debian.org>

To: 741573@bugs.debian.org

Cc: Nikolaus Rath <Nikolaus@rath.org>

Subject: Re: Bug#741573: Two menu systems

Date: Tue, 01 Jul 2014 08:58:17 +0200

On Monday 30 June 2014 23:23:53 Russ Allbery wrote:
> Isn't this the tool that Sune wrote and mentioned earlier in this bug as
> being incomplete and primarily useful for generating a template that
> requires subsequent work?

Correct.

The primary issue is that there isn't a 1:1 mapping between all categories. I 
don't exactly remember the exact categories, but an example could be that the 
debian menu format generally have a 'game' category, whereas the desktop file 
based spec has a hierarchy of game categories, where the top level should be 
empty.

by looking in the desktop2menu script in the giant mapping table for !WARN 
should show where the mapping can't be done, or there are no good actual 
match.

There is also, iirc, a couple of other oddities here and there that says I 
wouldn't want to use it in a automatic fashion.

I do think that arch's XdgMenu package is a much better approach for getting a 
xdg-based menu into various window managers, but it should really be 
maintained by someone in debian who has a use for it. (that will likely 
exclude Plasma users like me and Gnome users like Joss)

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Message #445 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Keith Packard <keithp@keithp.com>

To: Russ Allbery <rra@debian.org>, 741573@bugs.debian.org

Cc: 741573@bugs.debian.org, Nikolaus Rath <Nikolaus@rath.org>

Subject: Re: Bug#741573: Two menu systems

Date: Tue, 01 Jul 2014 09:47:39 -0700

[Message part 1 (text/plain, inline)]

Russ Allbery <rra@debian.org> writes:

> Isn't this the tool that Sune wrote and mentioned earlier in this bug as
> being incomplete and primarily useful for generating a template that
> requires subsequent work?

The only two gaps I saw were in the assignment of sections from the
Categories in the .desktop file, and in the construction of a suitable
.xpm icon. The former could easily be solved by extending the .desktop
format to include additional information to compute the section value
accurately.

-- 
keith.packard@intel.com

[Message part 2 (application/pgp-signature, inline)]

Message #450 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Fri, 25 Jul 2014 09:12:39 +0900

Le Mon, Jun 30, 2014 at 10:25:41PM -0700, Keith Packard a écrit :
> 
> I think this does demonstrate that we could, with little effort, allow
> applications to ship only .desktop files and have the menu package take
> those and generate menu files for other systems.

Hi Keith,

your approach is laudable, but most of what you propose has already been
discussed years before, and regardless how little the effort looks like, nobody
ever stepped in to implement it.

Instead, why not making a decision on whether it was acceptable or not to
revert a commit that had been seconded by enough developers and recognised as
consensual by a Policy editor ?  This is the core of the problem: the Policy
changes process works and there is no need for the CTTE to steer Debian's
policy on menus, it is just that the result of one year of consensus-building
it is blocked by a single person.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #455 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Harry-Werner <harless@netzero.net>

To: Debian Bug Tracking System <741573@bugs.debian.org>

Subject: tech-ctte: Window will not open.

Date: Tue, 16 Dec 2014 09:58:02 -0500

Package: tech-ctte
Followup-For: Bug #741573

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

When the first bar button on the top right corner of a window
is clicked the window will not size or open after being reduced to a bar.  

Message #460 received at 741573-done@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: Harry-Werner <harless@netzero.net>, 741573-done@bugs.debian.org

Subject: Re: Bug#741573: tech-ctte: Window will not open.

Date: Tue, 16 Dec 2014 16:13:47 +0100

Le mardi, 16 décembre 2014, 09.58:02 Harry-Werner a écrit :
> When the first bar button on the top right corner of a window
> is clicked the window will not size or open after being reduced to a
> bar.

tech-ctte is not the correct target for such a bug, I'm hereby closing 
this bug.

Please ask on debian-user@lists.debian.org to find help and a potential 
target package for a bug.

Cheers,
OdyX

Message #465 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: tech-ctte: Window will not open.

Date: Tue, 16 Dec 2014 16:19:23 +0100

Control: reopen -1 

Le mardi, 16 décembre 2014 16.13:47, OdyX a écrit :
> Le mardi, 16 décembre 2014, 09.58:02 Harry-Werner a écrit :
> > When the first bar button on the top right corner of a window
> > is clicked the window will not size or open after being reduced to a
> > bar.
> 
> tech-ctte is not the correct target for such a bug, I'm hereby closing
> this bug.

Woops, sorry; I thought it was a _new_ tech-ctte bug, not the long-
lasting 'menu' tech-ctte bug, sorry. Hereby Re-opening.

Cheers,
OdyX

Message #472 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Mon, 22 Dec 2014 14:29:44 +0000

Keith Packard writes ("Bug#741573: Two menu systems"):
> Yeah, there are a lot of inappropriate entries in my /usr/share/menu
> directory. Can we fix policy to weed these out? The current
> wording in §9.6:
> 
>       All packages that provide applications that need not be passed any
>       special command line arguments for normal operations should
>       register a menu entry for those applications.
> 
> seems problematic to me -- it seems to require menu entries for things
> as diverse as a web browser and a python interpreter. Coming up with
> wording that encourages only programs which are conventionally used in
> interactive mode to be included seems like a good fix here.

I think this is the heart of the disagreement.

The traditional Debian menu system (mostly done by Bill Alombert) has
been providing menu entries for bc and dc and everything for years.
That is what its users expect.  It is what users like Matthew Vernon
want:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#20

What you are suggesting above is that the Debian menu will simply be
abolished.  No-one will be allowed[1] to provide a comprehensive menu
in Debian.

The present dispute has arisen because, although the traditional
Debian menu maintainers do almost all of the work of providing all the
needed patches to enable packages to provide menu entries, some
package maintainers have decided to block that work by refusing the
patches.

It does appear that the users and developers of the .desktop-style
menus are in a majority.  But there are users who want to use the
comprehensive traditional Debian menu, and there are developers who
want to continue to do the work to keep it up to date.

We don't allow maintainers to block translation updates; we don't
expect them to block the provision of manpages (even though some
people think manpages are obsoluete); we shouldn't allow them to block
the trad menu system updates.

And we should certainly not tolerate this deliberate dismantling of a
working and maintained system, simply because some of its opponents
consider it obsolete.  A facility should be declared obsolete when it
no longer has maintainers who can (or want to) keep it working.

At the very least if we declare the trad menu system protocol
obsolete, there should be a clear plan for how to provide _the same
menus_ via .desktop files.  That *doesn't* mean `the menus that the
.desktop file proponents think everyone should want'.  It means `the
menus that the trad menu system users and developers currently have,
and actually want to keep'.

Ian.

[1]

I say `no-one will be allowed' because in the absence of support
from policy, attempts by menu developers to provide entries for
non-desktop programs, will be thwarted by the individual package
maintainers.

If I may extend the transation analogy: if we were to remove the
material about translations from Debian's normative documents, and
declare translations obsolete (in favour of English, I suppose),
no-one would be allowed to make a comperehensive translation of
Debian.  That is because there would be some maintainers who would
simply refuse to take translations on the grounds that translations
are obsolete and it's not worth the small effort to integrate
translation patches.

Message #477 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Tue, 23 Dec 2014 12:11:26 +0900

Dear TC,

I would like to react to Ian's message, that uses words like "deliberate
dismantling" that can be interpreted as if the misbehaviour is on my side, and
will add a remark on the fact that Policy maintainers have no "veto" in
contrary to what seemed implied in November's TC meeting on IRC.

First, there is no dismantling of the Debian menu in the Policy.  Ian calls
this menu "comprehensive", but the reality is that its coverage is patchy, in
sharp contrast with the "must" directive in the Policy.  The patch applied
changed this to a "should", which is a strong statement that is ground for
overriding maintainers refusing patches with no reason.  This adjustement of
the Policy to the current practice was the core answer to the original
requirement in #707851.

On top of this change I wanted to take the opportunity to brush up the Policy
by describing how to use FreeDesktop menu entries in Debian.  Very
unfortunately, this gave the impression that one menu system replaces the
other, but in practice it is two parallel changes.  This is why I am asking the
TC to refrain from refactoring that part of our work: it has full consensus,
and to be honest, I would feel it a big slap in my face (in the sense that it
would call for me reconsider if my contribution is really welcome) if the TC
would bypass the Policy change process to modify the changes related to the
FreeDesktop menu.

Ian's message goes in length on obstructive behaviours.  I disagree with such
behaviours and I think that the TC should override maintainers who deliberately
block the work of others for tactical reasons.  The obstruction discussed here
is the one of a Policy editor who ignored the Policy changes process and
engaged in an blocking strategy by withdrawing the discussion and then
reverting the consensus-driven changes unilaterally.  

In the Policy changes process there is no vote and there is no veto.  Bill had
ample time to make his points when the discussion was opened.  See through the
BTS entry: I took all the time needed - more than eight months ! - to address
people's reactions and seek consensus.  The consensus was assessed by a Policy
editor, which is the final point of the process.  Bill's behaviour turns the
whole discussion into a waste of time, and leaves the Policy in a state that
does not reflect the reality.  Far from increasing the coverage of the Debian
menu systems, Bills commit reversal undermines the value of Debian's policy
manual and sends the message that the personal opinion of Policy editors has
precedence on consensus (and the *work* that it represents to create that
consensus).

For this reason, sorry to repeat myself, I am asking the TC to please rule on
the question that I raised: should Bill's commit reversal be overriden ?

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #482 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <w@uter.be>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Two menu systems

Date: Sat, 27 Dec 2014 17:11:31 +0100

On Mon, 22 Dec 2014 14:29:44 +0000 Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> The traditional Debian menu system (mostly done by Bill Alombert) has
> been providing menu entries for bc and dc and everything for years.
> That is what its users expect.  It is what users like Matthew Vernon
> want:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#20
> 
> What you are suggesting above is that the Debian menu will simply be
> abolished.

This seems correct.

> No-one will be allowed[1] to provide a comprehensive menu in Debian.

This doesn't.

The trad menu system and the desktop menu system are both, in essence,
just a bunch of metadata. What's represented in that metadata is "how do
you start this particular bit of software". To that extent, they are the
same.

The actual *contents* of the trad menu system and the desktop menu
system is vastly different. I suspect that the opposition to losing the
trad menu system is not so much about the metadata *format* as it is
about the *contents* of those menu systems; about the actual menus that
result from interpreting the metadata.

But I don't see why that would need to be a problem, or indeed be part
of this question.

There is no reason why we wouldn't, theoretically, be able to build a
menu system that had a semantically similar (although perhaps differing
in minor details, such as "categories" etc) contents as does the trad
menu system, but using desktop metadata rather than trad metadata.

There is no reason why "moving to desktop files as supported menu
system" must imply "losing most or all of the contents that the trad
menu currently contains". It could, yes, and maybe it would make sense
if some of the more... "unusual" menu entries (such as those for "bash"
or "python") were removed from the menu system. However, that is a
wholly different question as to the question of which metadata format we
decide to go with, long-term.

I submit that the TC, for the purpose of answering this question before
it, should at first simply decide on a preferred metadata format. The
contents of the resulting menus is something they can then decide on as
a separate question (or ignore altogether if they decide it is not
appropriate for them to make that decision).

I will add that the debian menu is an all-or-nothing approach; TTBOMK it
is not possible to create an entry in the Debian menu saying something
along the lines of "this should not be shown by default" or "this should
not be shown by default in environment X". This might be one reason for
the choice of some of our DE maintainers to decide not to show the
Debian menu anymore.

The same is not true for the desktop metadata format.

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

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

Message #487 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: plessy@debian.org

Cc: 741573@bugs.debian.org

Subject: Requesting input on TC deliberations about menu system and policy

Date: Mon, 30 Mar 2015 20:32:58 -0400

Dear Charles,

Last Thursday, the TC met.  As part of that meeting we discussed
#741573.  See the logs at
http://meetbot.debian.net/debian-ctte/2015/debian-ctte.2015-03-26-18.59.log.html
.

Currently the plan is that Keith is  going to  propose some text within
the policy process that he believes might be a reasonable way forward.

You'd expressed some concern about the approach the TC is taking and we
were hoping to seek your input on where you think we are and on whether
we're moving forward in a reasonable way.

Speaking only for myself, it seems to me that there are a couple of
challenges that make it somewhat difficult to address the question of
whether the process was followed directly.  
Steve  claimed that the policy process is not a rough consensus process
and that the fact that Bill objected  in-and-of-itself might be
sufficient to argue that there was not consensus.
The process.txt document dated Spetember 14, 2014 does not support
Steve's claim.  I have not read previous versions of that document, and
I don't know which version of the process the TC should look at here.

Secondly, we've seen some argument within the TC that the policy
proposal might be technically flawed.  While I don't think we want to
second guess the process, at the end of the day we(the TC) have to be
comfortable with our technical policy.  I'd hope that if someone takes a
technically valid approach different than the one we would take, we'd
support the people doing the work taking the approach they favor.
However, if a valid process reaches a conclusion we think has
significant technical flaws, I would not ebxpect us to agree with that.

I haven't yet seen an explanation of the technical flaw that may exist
in the original policy proposal.

I think we'd rather see something everyone is happy with than have a
fight about process, but there does seem to be a number of people on the
TC who care strongly about respecting the work done within the
debian-policy list.

We'd really appreciate your input on where this stands and thoughts
about our current approach.

--Sam

Message #492 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Requesting input on TC deliberations about menu system and policy

Date: Tue, 31 Mar 2015 19:20:27 +0900

[I think that what follows is entirely redundant with what I wrote earlier.]

Le Mon, Mar 30, 2015 at 08:32:58PM -0400, Sam Hartman a écrit :
> 
> Steve  claimed that the policy process is not a rough consensus process
> and that the fact that Bill objected  in-and-of-itself might be
> sufficient to argue that there was not consensus.
> The process.txt document dated Spetember 14, 2014 does not support
> Steve's claim.  I have not read previous versions of that document, and
> I don't know which version of the process the TC should look at here.

Hi Sam,

thanks for your efforts in resolving this conflict.

After one year of discussion and negociation, following the "policy change
process", a consensus was found, with nobody standing up against it.  A couple
of weeks later, Bill abused his commit privileges and reverted the change.  I
think that this is clearly unacceptable, and I hope that the change on which
everybody worked on and agreed will be restored without further discussion.

If the TC insits on discussing, then the next question is what to discuss.  And
then you will realise that Bill's objections are still not clear as of today.
Since Bill makes no effort to discuss, I think that the discussion should stop
with the rejection of his objections.

In the end, what is at a stake here is not the menu systems.  The Debian menu
system is not a default anymore, and after the release we will see its
installation rate erode, and its usage to continue to fade away.  Blocking the
policy change has no effect, because already a large number of package
maintainers disregard that in theory, it is a "must" to have a menu entry for
every interactive program in Debian.

So what is at a stake here, is whether the Policy reflects the current
consensual and unchallenged practice, or whether it is lagging on real facts by
a couple for years or more.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #497 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: 741573@bugs.debian.org

Cc: Charles Plessy <plessy@debian.org>

Subject: Menu Systems: Thoughts about Next Steps

Date: Tue, 31 Mar 2015 12:07:22 -0400

Having reviewed the  policy team's process.txt document and having
reviewed Charles's comments, I'm much less sanguine when I think about
the approach for resolving the menu system discussion  that we discussed
last Thursday.

Keith may well have an approach that improves over both the status quo
and the version Russ committed.
However, he can rebase his diff   and propose it against whatever the
policy is when it gets to that point in the process.

I think there's significant value in  actually looking at the process
issue.

How would people feel about:

* Someone reads  #707851 to confirm  the facts presented.  In
  particular, confirm the seconds were made.

* We contact those who seconded confirming that by seconding they
  believed both that the proposal was good and that rough consensus was
  reached as described in the current process.txt document.

* We make an explicit call for unresolved  objections  to debian-policy,
  Bill and debian-ctte, giving people a couple of weeks.

* We ask those who seconded to help us understand whether objections
  that are raised were discussed, and if so, what the resolution was
  during the debian-policy discussion.

I get the impression that Steve at least believes that the proposal in
#707851 is not technically sound.  He may have raised that before either
here or in #707851.  At this point I have not read all the bug log for
either this bug or #707851, and it's long enough I probably never will.
Certainly if the TC believes the proposal is unsound that's going to
factor into what we do.

My hope is that an eventual resolution to this issue contains the
following points:

* Encourage Keith any anyone else who has improvements in this space to
  bring them up within the policy process, regardless of where we leave
  this issue.

* States that we expect those raising concerns about consensus to
  clearly articulate the objections they believe are unresolved.  Once a
  proposal has received enough positive interest, we expect those who do
  not articulate concerns and work so that their concerns are understood
  to stand aside rather than blocking the consensus process.  We hope
  the policy editors will hold themselves to the highest standard with
  regard to this point.  (wordsmithing required)

My thoughts about the rest of the resolution will depend on what
objections we find, our evaluation of soundness, etc.

I'd be interested in comments about this approach and peoples' feelings
about whether that's what we should do.

Message #502 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Bdale Garbee <bdale@gag.com>

Cc: 741573@bugs.debian.org

Subject: Re: Bug #741573:Process Approach vs Others

Date: Wed, 27 May 2015 21:19:07 -0400

[moving back to the bug, because we're starting to discuss the issue
rather than a TC communications matter.]


>>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
    Bdale> I hear you, I just don't have any idea what to do differently
    Bdale> on this specific issue in response to knowing how you feel
    Bdale> about it.

I made a specific proposal in #741573.  
I'd be a lot happier if you'd say "No, I think we've already reached
agreement that the policy team didn't have consensus., so we don't need to
evaluate whether the process was followed."
I wouldn't agree with that, but sometimes people disagree with you.  I'm
OK with that outcome.

If we've already agreed that the policy team didn't have consensus,  my
preference would be to ask the policy community whether they want us to
take up the issue, rather than just asserting a decision from on high.
That is, we communicate to them that we believe that they didn't have
consensus rather than just jumping to a conclusion.
I don't think we need to vote for that if we have internal rough
consensus, although I'd be fine voting on that if we wish to do so.

However:

    Bdale> Sam Hartman <hartmans@debian.org> writes:
    Bdale> I really think the only difference here might be in how much
    Bdale> of the process to date we've each been involved with.  When
    Bdale> this first hit the TC, I recall discussion about whether
    Bdale> policy process had run its course or not and my belief was
    Bdale> that we had consensus after input from Russ that in fact
    Bdale> policy process had failed here and it was appropriate for the
    Bdale> TC to intervene.  I would have to go do more digging and
    Bdale> reading to substantiate that assertion than I have time for
    Bdale> this afternoon, but that's the position I *thought* we agreed
    Bdale> we were in.

I've been reading this bug since the beginning even though I was not on
the TC.
I recall things differently.
Charles referred his question.
Ian jumped immediately to the technical discussion.
I wrote to Ian and the bug noting that he was jumping to the technical
discussion without considering the question Charles brought to the TC.
Ian wrote back  saying that it was inappropriate for the TC to consider
the question of whether the policy team had a consensus.
My perception is that everyone else ignored Charles and I and continued
on with the technical discussion.

Somewhere along that discussion a couple of TC members (I think you may
have been one) pointed out that going through the bug and determining
whether the policy team had consensus would be huge work.

So, if anything  the consensus of the TC prior to the resignations was
that it was not important to consider the question of whether the policy
team followed their process.

However a few things have happened since then:

* There has been a membership change in the TC.

* There's been a bunch of discussion within the TC and broader in the
  project that we might want to do a better job of working with folks.

* The policy team updated its process.  I don't know how extensive the
  update is, but it's my opinion that under the current process it's
  fairly easy to determine whether the policy team has consensus.
I proposed how to do so on this bug.
It may have been easy to do under the old process; I haven't researched
  that.

--Sam

Message #507 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: Bdale Garbee <bdale@gag.com>

Subject: Re: Bug#741573: Bug #741573:Process Approach vs Others

Date: Sat, 30 May 2015 17:41:46 +0200

On Wed, May 27, 2015 at 09:19:07PM -0400, Sam Hartman wrote:
> [moving back to the bug, because we're starting to discuss the issue
> rather than a TC communications matter.]
> 
> 
> >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
>     Bdale> I hear you, I just don't have any idea what to do differently
>     Bdale> on this specific issue in response to knowing how you feel
>     Bdale> about it.
> 
> I made a specific proposal in #741573.  
> I'd be a lot happier if you'd say "No, I think we've already reached
> agreement that the policy team didn't have consensus., so we don't need to
> evaluate whether the process was followed."
> I wouldn't agree with that, but sometimes people disagree with you.  I'm
> OK with that outcome.
> 
> If we've already agreed that the policy team didn't have consensus,  my
> preference would be to ask the policy community whether they want us to
> take up the issue, rather than just asserting a decision from on high.
> That is, we communicate to them that we believe that they didn't have
> consensus rather than just jumping to a conclusion.
> I don't think we need to vote for that if we have internal rough
> consensus, although I'd be fine voting on that if we wish to do so.

I also feel that we should check that the policy change process
has been followed as documented or not.  So from reading the
policy bug, it seems some of the Policy Editors think that there
is a consensus but that Bill Allombert doesn't agree that there is
one.

The DPL delegation text has this in it:
| Count seconds and weight objections to proposals, to determine whether
| they have reached sufficient consensus to be included, and accept
| consensual proposals.

The Policy Change Process does not document on how to handle
conflicts between the Policy Editors.

I would expect that each Policy Editor can make those decision,
and that once it's made an other Policy Editor can't just revert
that without following the Policy Change Process.


Kurt

Message #512 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: 741573@bugs.debian.org, Bdale Garbee <bdale@gag.com>

Subject: Re: Bug#741573: Bug #741573:Process Approach vs Others

Date: Sun, 31 May 2015 18:27:17 -0400

>>>>> "Kurt" == Kurt Roeckx <kurt@roeckx.be> writes:

    Kurt> On Wed, May 27, 2015 at 09:19:07PM -0400, Sam Hartman wrote:
    >> [moving back to the bug, because we're starting to discuss the
    >> issue rather than a TC communications matter.]
    >> 
    >> 
    >> >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
    Bdale> I hear you, I just don't have any idea what to do differently
    Bdale> on this specific issue in response to knowing how you feel
    Bdale> about it.
    >> 
    >> I made a specific proposal in #741573.  I'd be a lot happier if
    >> you'd say "No, I think we've already reached agreement that the
    >> policy team didn't have consensus., so we don't need to evaluate
    >> whether the process was followed."  I wouldn't agree with that,
    >> but sometimes people disagree with you.  I'm OK with that
    >> outcome.
    >> 
    >> If we've already agreed that the policy team didn't have
    >> consensus, my preference would be to ask the policy community
    >> whether they want us to take up the issue, rather than just
    >> asserting a decision from on high.  That is, we communicate to
    >> them that we believe that they didn't have consensus rather than
    >> just jumping to a conclusion.  I don't think we need to vote for
    >> that if we have internal rough consensus, although I'd be fine
    >> voting on that if we wish to do so.

    Kurt> I also feel that we should check that the policy change
    Kurt> process has been followed as documented or not.  So from
    Kurt> reading the policy bug, it seems some of the Policy Editors
    Kurt> think that there is a consensus but that Bill Allombert
    Kurt> doesn't agree that there is one.

    Kurt> The Policy Change Process does not document on how to handle
    Kurt> conflicts between the Policy Editors.

That's true, but  I proposed a way for the TC to resolve conflicts based
on our internal discussions of consensus and based on  my reading of the
policy process at
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=497;bug=741573

Yes, there's some interpretation on the part of the TC in doing that.
However, 1) I think that's always part of our job and 2) we have a lot
of constitutional room in how we approach policy it being one of our
primary mandates.

Message #517 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Bug #741573:Process Approach vs Others

Date: Thu, 11 Jun 2015 20:05:02 -0700

On Wed, 27 May 2015, Sam Hartman wrote:
> >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
>     Bdale> I hear you, I just don't have any idea what to do differently
>     Bdale> on this specific issue in response to knowing how you feel
>     Bdale> about it.
> 
> I made a specific proposal in #741573.  
> I'd be a lot happier if you'd say "No, I think we've already reached
> agreement that the policy team didn't have consensus., so we don't need to
> evaluate whether the process was followed."

I don't think we need to decide whether there was consensus or whether
the process was followed. I'm also not sure whether deciding that issue
would result in any actual difference in the outcome of this particular
issue:

  1) if we decide that there was consensus, we'll have to also decide in
  favor of the proposal that Charles did.

  2) if we decide that there wasn't, then we'll have effectively decided
  in favor of the status quo.

But that said, I recognize that you see a difference here, and it's
quite possible that I'm just not seeing it even though it actually is
there.

These are the options that I'm currently thinking about proposing to
resolve this issue. I think option B is the option which captures your
proposal, but feel free to propose any changes in that option in the
draft in git (or by e-mail).

Whereas:
       
   1. The Debian Technical Committee has been asked to resolve a
      dispute between maintainers of Debian Policy over a change that

      i. incorporates the description of the FreeDesktop menu system
         and its use in Debian for listing program in desktop menus
         and associating them with media types

     ii. softens the wording on the Debian Menu system to reflect that
         in Jessie it will be neither displayed nor installed by
         default on standard Debian installations.

 Using its power under §6.1.1 to decide matters of technical policy:

OPTION A:

   1. The Technical Committee adopts the changes proposed by Charles
      Plessy in ba679bff[1].

[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
      Debian menu package support translating .desktop files of
      packages which do not provide menu files.


OPTION B:
   1. Considers that the policy procedure resulted in consensus, and
      adopts the changes proposed by Charles Plessy in ba67bff.[1]

[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

OPTION C:

  1. The Technical Committee adopts the changes proposed by Bill
     Allombert.[1]

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446

OPTION Z:

Further discussion



-- 
Don Armstrong                      http://www.donarmstrong.com

Message #522 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Don Armstrong <don@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: Bug #741573:Process Approach vs Others

Date: Sun, 21 Jun 2015 15:06:47 -0400

>>>>> "Don" == Don Armstrong <don@debian.org> writes:

    Don> On Wed, 27 May 2015, Sam Hartman wrote:
    >> >>>>> "Bdale" == Bdale Garbee <bdale@gag.com> writes:
    Bdale> I hear you, I just don't have any idea what to do differently
    Bdale> on this specific issue in response to knowing how you feel
    Bdale> about it.
    >> 
    >> I made a specific proposal in #741573.  I'd be a lot happier if
    >> you'd say "No, I think we've already reached agreement that the
    >> policy team didn't have consensus., so we don't need to evaluate
    >> whether the process was followed."

    Don> I don't think we need to decide whether there was consensus or
    Don> whether the process was followed. I'm also not sure whether
    Don> deciding that issue would result in any actual difference in
    Don> the outcome of this particular issue:

Don, my concern is that I don't have the information I need to make a
decision between option B and option C.
I have a deeper long-term concern if the TC as a whole doesn't value the
process question: I don't think I could  be part of such a TC.

To recap, In order to figure out which wayp I would vote I'd want to:

 * Evaluate whether the claimed seconds were legitimate. I can do that
   on my own.

* Contact the people seconding and confirm that as part of seconding the
  proposal  they believed there was consensus.

* Provide a period (say a couple of weeks) in which Steve, Bill and
  others either on the TC or on the policy team could raise technical
  objections to Charles proposal.

I'll point out that we've been arguing for around two months about
whether to do something that takes two weeks of time.  You have not
explained your reasoning, so I'm not able to evaluate whether the time
is afactor in your concerns.  Those on the TC who have explained why
they think what I'm proposing is a bad idea seem to be saying that they
don't want to spend the additional time to do that work.  I'm frustrated
when I think that we've spent far more time discussing whether it is
worth collecting this information than it would have taken to collect
that information.

To be clear, I don't see a huge difference in option A and B.  I do see
a huge difference in voting on option A now vs stating a process we're
going to use that respects the policy team and following that process.

So, my preference would be to delay the vote and collect the information
in the bullet points above.
If you want a vote now and want an option on the ballot, how about:

D) The TC chooses to collect input from those seconding the proposal,
from the debian-policy list and from the TC.  

If you want something that better explains what input we want to collect
from each party I'd be happy to draft that.

--Sam

Message #527 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: Bug #741573:Process Approach vs Others

Date: Sun, 21 Jun 2015 15:32:54 -0700

On Sun, 21 Jun 2015, Sam Hartman wrote:
> my concern is that I don't have the information I need to make a
> decision between option B and option C.
> 
> To recap, In order to figure out which wayp I would vote I'd want to:
> 
>  * Evaluate whether the claimed seconds were legitimate. I can do that
>  on my own.
> 
> * Contact the people seconding and confirm that as part of seconding
> the proposal they believed there was consensus.

Please go ahead and do these two.

> * Provide a period (say a couple of weeks) in which Steve, Bill and
> others either on the TC or on the policy team could raise technical
> objections to Charles proposal.

I had hoped to start this part of the process by posting a specific
draft with options.

Once you're satisfied with #1 and #2, assuming there aren't objections
during Wednesday's meeting, in three weeks time I'd like to call for a
vote.

> You have not explained your reasoning, so I'm not able to evaluate
> whether the time is afactor in your concerns.

Total time and the amount of available time I have to deal with this
issue is one of my concerns. I'd like to spend the limited time I have
available dealing with the technical issue rather than the process
issue.

> I have a deeper long-term concern if the TC as a whole doesn't value
> the process question: I don't think I could be part of such a TC.

I think the process question is important because that's how decisions
are made when things work properly. I just think the process question is
orthogonal to the technical decision, and in addition to my concerns
above, I'm not convinced that the TC is the right body to decide whether
another group in Debian has followed their internal process.

But that doesn't mean that I should be standing in the way of members of
the TC who feel differently about that either.

Please go ahead and do #1 and #2 above as you suggest.

-- 
Don Armstrong                      http://www.donarmstrong.com

Message #532 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: 741573@bugs.debian.org

Cc: "Bernhard R. Link" <brlink@debian.org>, Markus Koschany <apo@gambaru.de>, Henrique de Moraes Holschuh <hmh@debian.org>, rra@debian.org, plessy@debian.org, kibi@debian.org, perezmeyer@gmail.com, lisandro@debian.org

Subject: Investigation of the bug log

Date: Tue, 23 Jun 2015 16:59:07 -0400

[Message part 1 (text/plain, inline)]

You are copied on this message because you raised objections noted by
the policy editors during the discussion of menu policy or seconded the
proposal in #707851.
The TC is currently evaluating a request to review that proposal and the
process surrounding it.

If you seconded the proposal, I'd like to confirm that as part of your
second, you believed that there was rough consensus and that objections
that were raised had been addressed.  That is, please confirm that you
evaluated not just the quality of the proposal, but also evaluated the
discussion.

If you have any outstanding objections to the proposal, I'd appreciate
you letting the TC know about those as well.

Hi, folks.
I took on the task of agreeing to evaluate the seconds expressed in
#707851.
to do that I grabbed the mbox and looked for seconds within it.
I see seconds from:

Cyril Brulebois  (who did not second the media handling portion)
Lisandro Damián Nicanor Pérez Meyer
Charles Plessy
Russ Allbery



however, in reviewing the bug log, I found a specific set of concerns
that Bill raised in his role as policy editor:

   After reviewing the buglog, I found there are a number of objection
   raised by various developers that have not been addressed. 

   This is a list of MSGID which have not received proper consideration:

   <20130512130335.GA4720@client.brlink.eu>
   <20130512100730.GA10956@yellowpig>
   <52E3BDE3.80707@gambaru.de>
   <20140125151743.GA25531@khazad-dum.debian.net>
   <52EE6A15.8090003@gambaru.de>

I'll take each of those messages and comment:
   <20130512130335.GA4720@client.brlink.eu>

"Bernhard R. Link" <brlink@debian.org>

Argument that the default should be show everything rather than only
show some applications.
basically an argument that  show everything would be a better default
and that it is valuable that the menu is consistent across environments.
Indicated he'd be OK with dropping menu and using XDG provided that the
policy was  that items are shown in the XDG menu unless there is a
technical reason not to.

My reading of this message is that in order to reach consensus the
question of whether showing all applications in the menu would need to
be considered by the policy process.
My strong suspicion is that issue was discussed and that Bernhard was in
the rough and that most people involved in the discussion considered the
arguments in favor of displaying all applications in the menu, but did
not agree with his position.

   <20130512100730.GA10956@yellowpig>

bill wonders  how many Window Managers support XDG.
So, the process would need to consider Window Managers that do not
support XDG in order to reach consensus with this message.

Bill also questions the behavior of GNOME, but that doesn't seem to be a
part of the policy discussion.

   <52E3BDE3.80707@gambaru.de>

Markus Koschany is concerned about making sure the Debian menu system is
mentioned in the policy to support the efforts of folks that are working
with it.
The proposal was changed in response to his concerns and he confirmed he
was happy with the text.

   <20140125151743.GA25531@khazad-dum.debian.net>

 Henrique de Moraes Holschuh <hmh@debian.org>
Seconds Markus's desire that the policy mention the menu system.

   <52EE6A15.8090003@gambaru.de>

markus is clarifying his concern.

[Message part 2 (application/pgp-signature, inline)]

Message #537 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

To: 741573@bugs.debian.org, Sam Hartman <hartmans@debian.org>

Cc: "Bernhard R. Link" <brlink@debian.org>, Markus Koschany <apo@gambaru.de>, Henrique de Moraes Holschuh <hmh@debian.org>, rra@debian.org, plessy@debian.org, kibi@debian.org

Subject: Re: Bug#741573: Investigation of the bug log

Date: Tue, 23 Jun 2015 19:36:42 -0300

[Message part 1 (text/plain, inline)]

Hi Sam! A long time has passed since then and I should re read the full and 
extensive bug log to assert whatever you want to ask. But I can be sure on one 
thing: at the time of issuing seconds, to the best of my knowledge, there 
where no counter-seconds. So I would say the process was followed, and I would 
really like not to dig into that again.

Now if you really need to go further you will need to allow me quite some time 
to recap the bug.

Regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #542 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Investigation of the bug log

Date: Tue, 23 Jun 2015 19:31:09 -0700

Sam Hartman <hartmans@debian.org> writes:

> You are copied on this message because you raised objections noted by
> the policy editors during the discussion of menu policy or seconded the
> proposal in #707851.  The TC is currently evaluating a request to review
> that proposal and the process surrounding it.

> If you seconded the proposal, I'd like to confirm that as part of your
> second, you believed that there was rough consensus and that objections
> that were raised had been addressed.  That is, please confirm that you
> evaluated not just the quality of the proposal, but also evaluated the
> discussion.

Hi Sam,

I did try to evaluate both the quality of the proposal and outcome of the
discussion, and thought that the people who had raised objections were in
the rough.  I may not have done a very good job of that, though.  (Also, I
felt like the proposal was a good path forward, which doesn't make me a
particularly unbiased judge of consensus.)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #547 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

Cc: 741573@bugs.debian.org, "Bernhard R. Link" <brlink@debian.org>, Markus Koschany <apo@gambaru.de>, Henrique de Moraes Holschuh <hmh@debian.org>, rra@debian.org, plessy@debian.org, kibi@debian.org

Subject: Re: Bug#741573: Investigation of the bug log

Date: Tue, 23 Jun 2015 23:49:45 -0400

>>>>> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> writes:

    Lisandro> Hi Sam! A long time has passed since then and I should re
    Lisandro> read the full and extensive bug log to assert whatever you
    Lisandro> want to ask. But I can be sure on one thing: at the time
    Lisandro> of issuing seconds, to the best of my knowledge, there
    Lisandro> where no counter-seconds. So I would say the process was
    Lisandro> followed, and I would really like not to dig into that
    Lisandro> again.

    Lisandro> Now if you really need to go further you will need to
    Lisandro> allow me quite some time to recap the bug.

What I'm hearing is that during the time you made the second you were
paying attention to the discussion and didn't believe there were any
counter-seconds--people jumping up and down saying their issues had not
been addressed?
If I've got that right, I think that's all we need at this point.

Message #552 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>

To: Sam Hartman <hartmans@debian.org>

Cc: 741573@bugs.debian.org, "Bernhard R. Link" <brlink@debian.org>, Markus Koschany <apo@gambaru.de>, Henrique de Moraes Holschuh <hmh@debian.org>, rra@debian.org, plessy@debian.org, kibi@debian.org

Subject: Re: Bug#741573: Investigation of the bug log

Date: Wed, 24 Jun 2015 10:19:47 -0300

[Message part 1 (text/plain, inline)]

On Tuesday 23 June 2015 23:49:45 Sam Hartman wrote:
> >>>>> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer 
<perezmeyer@gmail.com> writes:
[snip]
> What I'm hearing is that during the time you made the second you were
> paying attention to the discussion and didn't believe there were any
> counter-seconds--people jumping up and down saying their issues had not
> been addressed?
> If I've got that right, I think that's all we need at this point.

No, you are hearing a different thing ;)

What I'm saying is that the procedure at one point requires people to write a 
mail specifying that they are seconding the proposal. And I was one of them.
To the best of my knowledge no one counter-seconded the proposal in this way. 
So again, the process was followed.

Another thing is discussing the matter. Yes, I ack that there where some 
people who didn't like the idea, much in the same way that there are people 
who like the idea. No one of the two system is the panacea, so of course there 
would be always some kind of disagreement. But my position in that regard is 
that we had a rough consensus.

Hope that clarifies my previous mail :)

-- 
Yo quiero conocer el pensamiento de Dios, el resto son detalles.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[signature.asc (application/pgp-signature, inline)]

Message #557 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: "Bernhard R. Link" <brlink@debian.org>, Markus Koschany <apo@gambaru.de>, Henrique de Moraes Holschuh <hmh@debian.org>, rra@debian.org, plessy@debian.org, perezmeyer@gmail.com, lisandro@debian.org

Subject: Re: Bug#741573: Investigation of the bug log

Date: Wed, 24 Jun 2015 15:37:04 +0200

[Message part 1 (text/plain, inline)]

Hi Sam,

Thanks for taking a look at this old thread/topic.

Sam Hartman <hartmans@debian.org> (2015-06-23):
> If you seconded the proposal, I'd like to confirm that as part of your
> second, you believed that there was rough consensus and that objections
> that were raised had been addressed.  That is, please confirm that you
> evaluated not just the quality of the proposal, but also evaluated the
> discussion.

I'm confirming my second and the fact (IMHO) we've reached a consensus.
As Lisandro already mentioned in his reply, some were not quite happy
with the proposal, but that's life. I don't think anything in what you
quoted below refutes that consensus (especially the “please don't drop
menu entirely” argument which was rather smoothly addressed).

> I'll take each of those messages and comment: […]

Thanks again for your investigation efforts.

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #562 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org

Subject: Re: Investigation of the bug log

Date: Thu, 25 Jun 2015 08:14:33 +0900

Le Tue, Jun 23, 2015 at 04:59:07PM -0400, Sam Hartman a écrit :
> 
> If you seconded the proposal, I'd like to confirm that as part of your
> second, you believed that there was rough consensus and that objections
> that were raised had been addressed.  That is, please confirm that you
> evaluated not just the quality of the proposal, but also evaluated the
> discussion.

Hi Sam,

I confirm that when seconding the proposal, it was my assessemnt that a rough
consensus has been reached.  As a former Policy Editor, I was well aware that
seconding is not merly a voting process.

Have a nice day,

-- 
Charles

Message #567 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@gambaru.de>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: "Bernhard R. Link" <brlink@debian.org>, Henrique de Moraes Holschuh <hmh@debian.org>, rra@debian.org, plessy@debian.org, kibi@debian.org, perezmeyer@gmail.com, lisandro@debian.org

Subject: Re: Investigation of the bug log

Date: Sat, 27 Jun 2015 19:10:18 +0200

[Message part 1 (text/plain, inline)]

Hello Sam,

Sorry for the delay. I had to re-read the bug log again.

tl;dr

I think that a consensus was reached and my concerns have been addressed
in #707851.

I have mainly participated in this discussion because I have gained some
insight into the Debian menu versus XDG situation while I was working on

https://wiki.debian.org/Games/JessieReleaseGoal

It was important for me that the Debian menu is still mentioned as an
alternative menu system, for reasons I would like to summarize again. I
think much of the controversity could have been avoided if people had
refrained from phrases like "getting rid of or killing" the menu system
and instead had discussed the original proposal "to soften the wording
recommending menu files" as a first step, because we are not ready for
step two yet. Removing the Debian menu system at this point in time
would be a unnecessary regression but it should be a goal for the future.

I recommend that the TC confirms the outcome of the discussion in bug
#707851 but also reaffirms that the Debian menu is still an alternative
menu system. That means menu file patches should be accepted and current
packages should not drop them. The TC should also encourage maintainers
to accept patches to implement the XDG spec, to ship desktop files and
to work on the goal to unify the desktop appearance for all desktop
users in Debian by improving the support for this specification for all
window managers and desktop environments.

The second step would be to package tools like archlinux-xdg-menu or
awesome-freedesktop and has been mentioned before,

https://wiki.archlinux.org/index.php/XdgMenu
https://github.com/terceiro/awesome-freedesktop

and to create a Lintian warning for missing desktop files and to fix
those issues.
As soon as the Freedesktop Standard is widely adopted by the majority of
window managers and desktop environments and the vast majority of
applications ship desktop files, we could phase out the
Debian menu and eventually "get rid of" menu files for good.


I completely agree that the Policy should recommend the Freedesktop
Specification because it is de facto standard for all major desktop
environments. It is also widely supported across different distributions
and nowadays application developers exclusively provide desktop files
for their programs. I have never observed anything different. This is
the most important argument for changing the Policy because it should
reflect the reality and common practice. The synergy effects with
upstream developers and other distributions are enormous.

I believe the current wording is sensible, at least how I interpret it,
because it strikes a balance between the above mentioned reality and the
fact that the Debian menu is still useful for lightweight window manager
setups where it is known to integrate well and where it provides value
for users. The user base is not as large as it is for GNOME or KDE but
it is not insignificant either which can be verified by looking at
popcon statistics for Fluxbox, Openbox or IceWM, just to mention a few
of the 40+ window managers in Debian.

In my opinion Bill's concerns are addressed by ensuring that the Debian
menu is still considered as an alternative as long as the XDG menu does
not provide the same value for window manager setups. Someone has to do
the work and investigate how many WM's really support the XDG menu and
package the required tools to make the Debian menu superfluous.

Although I sympathise with Bill's general approach to keep the Debian
menu system for the time being, I do not agree with his actions to
revert Charles' changes unilaterally. I cannot imagine a
better and more thorough way to conduct such a Policy change and Charles
really tried to incorporate the comments and even asked on debian-devel
for more input.

Some comments to statements about the Debian menu
=================================================

1. It is not hard to test menu files. You can install Openbox and the
menu package alongside Gnome3 for example and switch between the two. It
is also trivial to verify the validity of a menu file by using visual
inspection.

2. Menu files are not hard to maintain. In fact under normal
circumstances you will never have to touch them again and dh_installmenu
is a great helper.

3. 95 source packages from the games specific release goal do not ship
desktop files but they still support menu files.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-games-devel@lists.alioth.debian.org;tag=desktop-integration

I only know the games situation but there might be a lot more packages
that still don't support the XDG spec. I presume the KDE, GNOME and Xfce
folks would also like to see this changed. Here we should begin.

Regards,

Markus

[signature.asc (application/pgp-signature, attachment)]

Message #572 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: debian-policy@lists.debian.org,741573@bugs.debian.org

Subject: #741573: Menu Policy and Consensus

Date: Fri, 17 Jul 2015 18:07:38 -0400

[Message part 1 (text/plain, inline)]

In March of 2014, Charles Plessy asked the Debian Technical Committee to
review one of the policy editors decisions to revert changes to how
policy talks about the Debian Menu and MIME support.  See
http://bugs.debian.org/741573 for the TC process and
https://bugs.debian.org/707851.  for the process within debian-policy.

One of the issues is the question of whether the Debian Policy community
reached consensus around the proposal.  I've investigated this question
as part of trying to understand how I will vote within the TC process.

I had hoped to get the TC as a whole interested in the question of
whether consensus had been reached, but while several TC members have
joined that discussion, it seems that the TC as a whole will not address
that question.


However, I've tried to investigate the process.
I draw your attention to
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=497;bug=741573 .
In that message I outlined my plan for how I'd review whether consensus
was reached as a TC member.

It's probably worth taking a look at that message even if you don't care
about the issue.
I propose that a reasonable way for the TC or anyone else for that
matter to evaluate consensus is to:

* Confirm from the bug log that a proposal gained enough seconds

* Confirm that the people seconding believe (as required by the
  process.txt document) both that the proposal is sound/complete and
  that it has reached consensus.

* Make an explicit call for unresolved technical objections and if any
  objections areraised, consider them. [1]

[1] Note that consider  is complex.  RFC 7282  gives thoughts that some
folks have had on some of these issues in cases where you have agreement
that the work should be done and are trying to come to rough consensus
on how to do it.  Issues like whether the issue has been considered
before, whether it was understood when considered, etc all are
important.  Evaluating rough consensus once you get to a point where you
have objections is kind of an art form.

If my approach does not seem reasonable then I'd recommend revising
process.txt to give better guidance to folks reviewing your work.

I tried to implement my approach.

It is my belief that rough consensus was achieved.  Those who seconded
the proposal more-than-less reviewed the discussion for rough
consensus.  I also looked at significant chunks of the discussion
including the list of objections that Bill raised.
It's my belief that the objections Bill raised were discussed by the
broader community and his points were considered.
It's my belief that the other objections he pointed to (other than his
own) in his mail indicating he'd reverted the change were explicitly
addressed.  In at least one case I got confirmation of that from the
person raising the objection.

That said, I'd like to draw your attention to two of the mails I got
asking people to review seconds and to the  process text surrounding
seconds.  These responses are on the edge with regard to whether the
person seconding actually met the process requirement of evaluating
rough consensus.  If someone wanted to argue that no consensus was
reached, these two seconds would be one way to make such an argument.


    What needs to happen next: The proposal needs to be reviewed and
    seconded. Any Debian developer who agrees with the change and the
    conclusion of rough consensus from the discussion should say so in the
    bug log by seconding the proposal.


    [TAG: patch]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch

    State E: Seconded 
    ------------------

    The proposal is signed off on by N Debian Developers. To start with,
    we're going with N=3, meaning that if three Debian Developers agree,
    not just with the proposal but with the conclusion that it reflects
    consensus and addresses the original issue -- it is considered
    eligible for inclusion in the next version of Policy. Since Policy is
    partly a technical project governance method, one must be a Debian
    Developer to formally second, although review and discussion is
    welcome from anyone. Once this tag has been applied, the bug is
    waiting for a Policy team member to apply the patch to the package


Now, I ask you to consider Lisandro Damián Nicanor Pérez Meyer 's
response to my question about his second:

    Sam> What I'm hearing is that during the time you made the second you were
    Sam> paying attention to the discussion and didn't believe there were any
    Sam> counter-seconds--people jumping up and down saying their issues had not
    Sam> been addressed?
    Sam> If I've got that right, I think that's all we need at this point.

    No, you are hearing a different thing ;)

    What I'm saying is that the procedure at one point requires people to write a 
    mail specifying that they are seconding the proposal. And I was one of them.
    To the best of my knowledge no one counter-seconded the proposal in this way. 
    So again, the process was followed.

    Another thing is discussing the matter. Yes, I ack that there where some 
    people who didn't like the idea, much in the same way that there are people 
    who like the idea. No one of the two system is the panacea, so of course there 
    would be always some kind of disagreement. But my position in that regard is 
    that we had a rough consensus.

    Hope that clarifies my previous mail :)

And from Russ Allbery:
    > You are copied on this message because you raised objections noted by
    > the policy editors during the discussion of menu policy or seconded the
    > proposal in #707851.  The TC is currently evaluating a request to review
    > that proposal and the process surrounding it.

    > If you seconded the proposal, I'd like to confirm that as part of your
    > second, you believed that there was rough consensus and that objections
    > that were raised had been addressed.  That is, please confirm that you
    > evaluated not just the quality of the proposal, but also evaluated the
    > discussion.

    Hi Sam,

    I did try to evaluate both the quality of the proposal and outcome of the
    discussion, and thought that the people who had raised objections were in
    the rough.  I may not have done a very good job of that, though.  (Also, I
    felt like the proposal was a good path forward, which doesn't make me a
    particularly unbiased judge of consensus.)


Sam hartman
Speaking only for myself

[Message part 2 (application/pgp-signature, inline)]

Message #577 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: debian-policy@lists.debian.org, 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Sat, 18 Jul 2015 14:33:00 +0200

On Fri, Jul 17, 2015 at 10:08:04PM +0000, Sam Hartman wrote:
> In March of 2014, Charles Plessy asked the Debian Technical Committee to
> review one of the policy editors decisions to revert changes to how
> policy talks about the Debian Menu and MIME support.  See
> http://bugs.debian.org/741573 for the TC process and
> https://bugs.debian.org/707851.  for the process within debian-policy.
> 
> One of the issues is the question of whether the Debian Policy community
> reached consensus around the proposal.  I've investigated this question
> as part of trying to understand how I will vote within the TC process.

I want to point out that I have split the menu policy changes in 3 parts, so that
the less controversial part could be decided separately, see #742532.
However nobody was interested in seconding this. So I am let to believe there
is no actual consensus on this.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #582 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: debian-policy@lists.debian.org

Cc: 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Sat, 18 Jul 2015 09:56:45 -0400

>>>>> "Bill" == Bill Allombert <ballombe@debian.org> writes:

    Bill> On Fri, Jul 17, 2015 at 10:08:04PM +0000, Sam Hartman wrote:
    >> In March of 2014, Charles Plessy asked the Debian Technical
    >> Committee to review one of the policy editors decisions to revert
    >> changes to how policy talks about the Debian Menu and MIME
    >> support.  See http://bugs.debian.org/741573 for the TC process
    >> and https://bugs.debian.org/707851.  for the process within
    >> debian-policy.
    >> 
    >> One of the issues is the question of whether the Debian Policy
    >> community reached consensus around the proposal.  I've
    >> investigated this question as part of trying to understand how I
    >> will vote within the TC process.

    Bill> I want to point out that I have split the menu policy changes
    Bill> in 3 parts, so that the less controversial part could be
    Bill> decided separately, see #742532.  However nobody was
    Bill> interested in seconding this. So I am let to believe there is
    Bill> no actual consensus on this.

I agree that there doesn't seem to be consensus on your proposed split.

I don't think I can infer anything about the overall proposal's support
from lack of support for the split.  As an example, if I had high
confidence that I could get consensus on the entire proposal, I would
not generally support handling the less contraversial parts first.

If you handle the less-controversial parts first, it's easy to get into
a situation where that's all you solve.  When you do that because you
honestly can't get consensus on more than the less-controversial parts,
the process is working.  However, sometimes those sort of splits can
create dynamics where you get less of a solution than you might hope.

Message #587 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: debian-policy@lists.debian.org, 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Sun, 19 Jul 2015 09:31:30 +0900

Le Sat, Jul 18, 2015 at 01:56:49PM +0000, Sam Hartman a écrit :
> >>>>> "Bill" == Bill Allombert <ballombe@debian.org> writes:
> 
>     Bill> I want to point out that I have split the menu policy changes
>     Bill> in 3 parts, so that the less controversial part could be
>     Bill> decided separately, see #742532.  However nobody was
>     Bill> interested in seconding this. So I am let to believe there is
>     Bill> no actual consensus on this.
> 
> I agree that there doesn't seem to be consensus on your proposed split.

Hello everybody,

I am not willing to enter discussions on whether I agree on subsets of a
proposal that I already approved as a whole in totality.  This is a waste of
time (that reminds me Zenon's paradox).

Also, the question is not whether the FreeDesktop menu should be described in
the Policy or not, or how to split the proposal in 3, 4 or 42 parts.  It is not
even on whether the Debian menu should be a "must" or a "should", because for
that as well, we got a "rough consensus", where at the end of the process there
was only a single person opposing the change.  Neither it is about re-starting
a search for people disagreeing (or shall I restart a GR on systemd ?).  The
question is whether a single individual can engage in confrontational commit
wars to block changes in Debian.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #592 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: debian-policy@lists.debian.org, Bill Allombert <ballombe@debian.org>

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Sun, 19 Jul 2015 03:06:27 +0200

[Message part 1 (text/plain, inline)]

Sam Hartman <hartmans@debian.org> (2015-07-18):
> >>>>> "Bill" == Bill Allombert <ballombe@debian.org> writes:
> 
>     Bill> On Fri, Jul 17, 2015 at 10:08:04PM +0000, Sam Hartman wrote:
>     >> In March of 2014, Charles Plessy asked the Debian Technical
>     >> Committee to review one of the policy editors decisions to revert
>     >> changes to how policy talks about the Debian Menu and MIME
>     >> support.  See http://bugs.debian.org/741573 for the TC process
>     >> and https://bugs.debian.org/707851.  for the process within
>     >> debian-policy.
>     >> 
>     >> One of the issues is the question of whether the Debian Policy
>     >> community reached consensus around the proposal.  I've
>     >> investigated this question as part of trying to understand how I
>     >> will vote within the TC process.
> 
>     Bill> I want to point out that I have split the menu policy changes
>     Bill> in 3 parts, so that the less controversial part could be
>     Bill> decided separately, see #742532.  However nobody was
>     Bill> interested in seconding this. So I am let to believe there is
>     Bill> no actual consensus on this.
> 
> I agree that there doesn't seem to be consensus on your proposed split.
> 
> I don't think I can infer anything about the overall proposal's support
> from lack of support for the split.  As an example, if I had high
> confidence that I could get consensus on the entire proposal, I would
> not generally support handling the less contraversial parts first.
> 
> If you handle the less-controversial parts first, it's easy to get into
> a situation where that's all you solve.  When you do that because you
> honestly can't get consensus on more than the less-controversial parts,
> the process is working.  However, sometimes those sort of splits can
> create dynamics where you get less of a solution than you might hope.

Well, trying to split topics, menu policy changes, or hairs, seems (at
least to me) to be the new trick of the day to cover up the inexcusable
behaviour that Charles described when he opened up this very bug report.

Wasting people's hard work, and then using a lack of reply to an extra
round of nitpicking as an excuse for having wasted the whole lot?

Shame on you, Bill.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #597 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: debian-policy@lists.debian.org, 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Sun, 19 Jul 2015 04:05:45 -0400

[Message part 1 (text/plain, inline)]

>>>>> "Charles" == Charles Plessy <plessy@debian.org> writes:

    Charles> Le Sat, Jul 18, 2015 at 01:56:49PM +0000, Sam Hartman a
    Charles> écrit :
    >> >>>>> "Bill" == Bill Allombert <ballombe@debian.org> writes:

    Charles> Also, the question is not whether the FreeDesktop menu
    Charles> should be described in the Policy or not, or how to split
    Charles> the proposal in 3, 4 or 42 parts.  It is not even on
    Charles> whether the Debian menu should be a "must" or a "should",
    Charles> because for that as well, we got a "rough consensus", where
    Charles> at the end of the process there was only a single person
    Charles> opposing the change.  Neither it is about re-starting a
    Charles> search for people disagreeing (or shall I restart a GR on
    Charles> systemd ?).  The question is whether a single individual
    Charles> can engage in confrontational commit wars to block changes
    Charles> in Debian.

I hear your frustration that a proposal you worked on has been blocked
for over a year by the actions of one person.
For myself, though, I'd like to think of the questions differently,
because I'd like to grow from this experience.

Bill, in his role of policy editor said that he believed there was not a
consensus.  He cited a specific set of messages that he believes were
not properly addressed.
I do think it is the job of policy editors to be involved in judging
consensus.
I've been in the position of judging consensus, and made unpopular
calls.
It's hard.  You know you'll face others with strong negative feelings.
You're typically worried about whether you're making the right call.
You're typically hopeful that others will clearly see your point even
when they disagree.  You're frustrated when that doesn't happen.

While I disagree with Bill, I respect him when he makes a hard call like
that.

I agree with Charles though that one person should not be able to block
the process.

My hope for improvement is in how we handle things when a policy editor
or someone else in a similar role in the project claims we don't have
consensus.  What do we expect from our consensus judgers moving forward
in such situations?  What do we expect from ourselves as advocates of
proposals?  What is the process?

I'd like to share a couple of my thoughts.  I'm nervous that in doing so
I'll bias the discussion more than I like.  However, I'm more concerned
that unless I give some constructive examples of  what I'm talking
about, it will be hard to move forward.

A lot of my experience with consensus process is in the IETF.  There, if
you're in a position to judge consensus, you have an obligation to help
try and build the consensus when you judge that there is not consensus.
If you're in a position to judge consensus, you have an obligation to
lead the discussion, to focus on areas of disagreement, and to see if
your consensus call is correct.  There's an expectation that when you
call a lack of consensus, getting to consensus is going to be a
priority, and you're going to put in significant time to help.

Should some or all of the above be part of what we expect from policy
editors?

On another axis of the discussion, what's the appeals process?  Where do
you go when the discussion stalls or reaches an impass?  (In general,
that should not be the immediate reaction to a call of lack of
consensus; such a call is generally the start of a very fast-paced
discussion.)
Charles tried the TC in this instance.
I think the TC has the expertise to review the technical aspects of
these matters.  I think that's actually important to reviewing a
consensus discussion, and is most of the skills you'd need to review
this sort of consensus evaluation.

However, I think the TC might be more effective in situations like this
if it better understood its role.  There was significant disagreement
between the members of the TC Charles brought the issue to and Charles
about what the role of the TC should be.  During the process, the TC
membership changed, and today, I'd say that the TC is probably unsure
what its role should be here.  For reasons I don't fully understand, the
TC process was slower than I'd like.

I hope by focusing on questions like these we can grow from this
experience and be better positioned to resolve future situations where
we're unsure about consensus.  I hope we can treat everyone with
respect--those judging consensus, those reviewing that decision, those
disagreeing with that decision, and those who just want to see forward
progress.

thanks for your consideration.

--Sam

[Message part 2 (application/pgp-signature, inline)]

Message #602 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: debian-policy@lists.debian.org, 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Sun, 19 Jul 2015 21:39:50 +0900

Le Sun, Jul 19, 2015 at 08:05:56AM +0000, Sam Hartman a écrit :
> 
> Bill, in his role of policy editor said that he believed there was not a
> consensus.

Hi Sam,

I think that what you wrote does not reflect what happened:

 - Russ gave me the green light for committing the changes, see
   <https://lists.debian.org/debian-policy/2014/02/msg00068.html>.  Only Policy
   Editors can decide that a change will be committed, thus it is my understanding
   that Russ, as a Policy Editor, judged that there was consensus.

 - Without consulting with the other Policy Editors, Bill reverted the commit.
   This solo action was done out of the usual process for seeking consensus
   before changing the Policy.

> A lot of my experience with consensus process is in the IETF.  There, if
> you're in a position to judge consensus, you have an obligation to help
> try and build the consensus when you judge that there is not consensus.
> If you're in a position to judge consensus, you have an obligation to
> lead the discussion, to focus on areas of disagreement, and to see if
> your consensus call is correct.  There's an expectation that when you
> call a lack of consensus, getting to consensus is going to be a
> priority, and you're going to put in significant time to help.
> 
> Should some or all of the above be part of what we expect from policy
> editors?

I totally share this point of view.  (This is why after leading the release of
the Policy version 3.9.5.0, seeing that I would not have time to do the same
within a year or two, I quitted as a Policy Editor).

> On another axis of the discussion, what's the appeals process?

The only appeal I would see would be through the DPL, since he appoints and
replaces the Policy Editors, who are DPL delegates.

Have a nice Sunday,

PS: I will be on business trip in Trieste for one week.

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #607 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: debian-policy@lists.debian.org, 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Sun, 19 Jul 2015 09:10:25 -0400

>>>>> "Charles" == Charles Plessy <plessy@debian.org> writes:

    Charles> Le Sun, Jul 19, 2015 at 08:05:56AM +0000, Sam Hartman a
    Charles> écrit :
    >> 
    >> Bill, in his role of policy editor said that he believed there
    >> was not a consensus.

    Charles> Hi Sam,

    Charles> I think that what you wrote does not reflect what happened:

    Charles>  - Russ gave me the green light for committing the changes,
    Charles> see
    Charles> <https://lists.debian.org/debian-policy/2014/02/msg00068.html>.
    Charles> Only Policy Editors can decide that a change will be
    Charles> committed, thus it is my understanding that Russ, as a
    Charles> Policy Editor, judged that there was consensus.
I agree with that.

    Charles>  - Without consulting with the other Policy Editors, Bill
    Charles> reverted the commit.  This solo action was done out of the
    Charles> usual process for seeking consensus before changing the
    Charles> Policy.

Well, I'd phrase it as Bill, in his role as policy editor felt that Russ
had misjudged consensus.
My understanding is that the process is silent on this: it neither
permits nor forbids this.

I actually think you want the process to permit policy editors to
disagree with each other in this way.
There's some question about how to handle a disagreement when it arises.
Immediately reverting is an option that tends to maximize frustration,
especially if it is not explicitly called out in the process.

    >> A lot of my experience with consensus process is in the IETF.
    >> There, if you're in a position to judge consensus, you have an
    >> obligation to help try and build the consensus when you judge
    >> that there is not consensus.  If you're in a position to judge
    >> consensus, you have an obligation to lead the discussion, to
    >> focus on areas of disagreement, and to see if your consensus call
    >> is correct.  There's an expectation that when you call a lack of
    >> consensus, getting to consensus is going to be a priority, and
    >> you're going to put in significant time to help.
    >> 
    >> Should some or all of the above be part of what we expect from
    >> policy editors?

    Charles> I totally share this point of view.  (This is why after
    Charles> leading the release of the Policy version 3.9.5.0, seeing
    Charles> that I would not have time to do the same within a year or
    Charles> two, I quitted as a Policy Editor).

OK.
If there's general agreement on this, it might be a good idea to get
this expectation into  the process document and reference that from the
delegation.
Naturally as part of that you'd want to make sure that the policy
editors are comfortable with the responsibility the community is asking
them to take up.

    >> On another axis of the discussion, what's the appeals process?

    Charles> The only appeal I would see would be through the DPL, since
    Charles> he appoints and replaces the Policy Editors, who are DPL
    Charles> delegates.

Well, I'll note that's not what you did; you brought the issue to the TC
rather than the DPL.
I'll also note that our constitution explicitly limits the DPL's actions
with regard to a decision of a delegate.

I think the DPL is who you'd bring an issue to if you thought an editor
was consistently not meeting the responsibility of the post.  I think
the DPL has no formal power to reverse a specific decision.

Message #612 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Cyril Brulebois <kibi@debian.org>

Cc: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org, debian-policy@lists.debian.org, Bill Allombert <ballombe@debian.org>

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Mon, 20 Jul 2015 15:39:09 +0200

On Sun, Jul 19, 2015 at 03:06:27AM +0200, Cyril Brulebois wrote:
> Wasting people's hard work, and then using a lack of reply to an extra
> round of nitpicking as an excuse for having wasted the whole lot?

The only hard work here is maintaining the menu system for ten years.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #617 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: Sam Hartman <hartmans@debian.org>, debian-policy@lists.debian.org, 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Mon, 20 Jul 2015 15:42:36 +0200

On Sun, Jul 19, 2015 at 09:39:50PM +0900, Charles Plessy wrote:
> Le Sun, Jul 19, 2015 at 08:05:56AM +0000, Sam Hartman a écrit :
> > 
> > Bill, in his role of policy editor said that he believed there was not a
> > consensus.
> 
> Hi Sam,
> 
> I think that what you wrote does not reflect what happened:
> 
>  - Russ gave me the green light for committing the changes, see
>    <https://lists.debian.org/debian-policy/2014/02/msg00068.html>.  Only Policy
>    Editors can decide that a change will be committed, thus it is my understanding
>    that Russ, as a Policy Editor, judged that there was consensus.

This is not my understanding. It seemed clear that Russ did not have time to do
such review but trusted you as former policy editor. However I really did not
expect you to use commit right you should not have had anymore to force the isssue.

Cheers,
Bill.

Message #622 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: ballombe@debian.org

Cc: 741573@bugs.debian.org

Subject: Russ's role

Date: Mon, 20 Jul 2015 10:34:47 -0400

You said:
> 
> I think that what you wrote does not reflect what happened:
> 
Charles>  - Russ gave me the green light for committing the changes, see
Charles>    <https://lists.debian.org/debian-policy/2014/02/msg00068.html>.  Only Policy
Charles>    Editors can decide that a change will be committed, thus it is my understanding
Charles>    that Russ, as a Policy Editor, judged that there was consensus.

Bill>This is not my understanding. It seemed clear that Russ did not have time to do
Bill> such review but trusted you as former policy editor. However I really did not
Bill> expect you to use commit right you should not have had anymore to
Bill> force the isssue.

Hi.
As a matter of fact finding.
Russ's message, which Charles sites implies to me that Russ was swamped
and didn't have time to do the commit.  By seconding, he had already
done the review.
That's consistent with what he said in this bug about his second (quoted
in my mail to debian-policy last week)

Message #627 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: ballombe@debian.org, 741573@bugs.debian.org

Subject: Re: Russ's role

Date: Mon, 20 Jul 2015 16:49:53 +0200

On Mon, Jul 20, 2015 at 10:34:47AM -0400, Sam Hartman wrote:
> You said:
> > 
> > I think that what you wrote does not reflect what happened:
> > 
> Charles>  - Russ gave me the green light for committing the changes, see
> Charles>    <https://lists.debian.org/debian-policy/2014/02/msg00068.html>.  Only Policy
> Charles>    Editors can decide that a change will be committed, thus it is my understanding
> Charles>    that Russ, as a Policy Editor, judged that there was consensus.
> 
> Bill>This is not my understanding. It seemed clear that Russ did not have time to do
> Bill> such review but trusted you as former policy editor. However I really did not
> Bill> expect you to use commit right you should not have had anymore to
> Bill> force the isssue.
> 
> Hi.
> As a matter of fact finding.
> Russ's message, which Charles sites implies to me that Russ was swamped
> and didn't have time to do the commit.  By seconding, he had already
> done the review.

Seconding a bug does not imply doing a consensus search, even for a policy
editor.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #632 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Mon, 20 Jul 2015 17:14:03 +0200

Sam Hartman <hartmans@debian.org> wrote: 
        Bill, in his role of policy editor said that he believed there was not a
        consensus.  He cited a specific set of messages that he believes were
        not properly addressed.

From the beginning, I have been puzzled by your approach to this issue.
With this paragraph, I think I’m beginning to understand how you want to
treat the issue. And I can’t say I think it is constructive.

Bill used his position as a policy editor to reject a change, not
because it was against consensus or against the policy process, but
because it was against his own opinion. Not as policy editor, but as
menu maintainer. 

This is the root of the problem. By asking whether the policy process
has been respected, you are reversing the responsibility. It was Bill’s
responsibility from day one to recuse himself from policy decisions on
the menu.
It was also Bill’s responsibility, from day one, to raise his own
concerns to the policy change being discussed, not to rely on other
people’s nitpicks *after* the new policy had been approved and
committed.

Maybe, after all, this issue should not have been sent to the TC but to
the DPL, to ask for the revocation of the abused delegation. 

-- 
Joss

Message #637 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: Sam Hartman <hartmans@debian.org>, debian-policy@lists.debian.org, 741573@bugs.debian.org

Subject: Re: #741573: Menu Policy and Consensus

Date: Mon, 20 Jul 2015 10:46:26 -0700

Bill Allombert <ballombe@debian.org> writes:
> On Sun, Jul 19, 2015 at 09:39:50PM +0900, Charles Plessy wrote:

>> I think that what you wrote does not reflect what happened:
>> 
>>  - Russ gave me the green light for committing the changes, see
>>    <https://lists.debian.org/debian-policy/2014/02/msg00068.html>.
>>    Only Policy Editors can decide that a change will be committed, thus
>>    it is my understanding that Russ, as a Policy Editor, judged that
>>    there was consensus.

> This is not my understanding. It seemed clear that Russ did not have
> time to do such review but trusted you as former policy editor. However
> I really did not expect you to use commit right you should not have had
> anymore to force the isssue.

It would be nice if I could clear this up unambiguously, but this is like
so many other things in life: it was both of those and more.

I did feel that the time that there was consensus, and wouldn't have told
Charles to go ahead if I hadn't.  However, I also personally believed his
approach was correct, and I didn't do a particularly exhaustive job of
separating that impression from my attempt to determine consensus.  I
wasn't sure how strongly you objected, and I have a bias for keeping
things moving forward.

When you felt strongly enough about this to revert it, I personally was
happy to have someone else make a final decision, partly because I didn't
have much time to pursue it further.

So I don't think it's really correct to say that I just trusted Charles.
I did my own evaluation of consensus.  However, at the same time, I
wouldn't argue that it was the best evaluation of consensus I ever did,
and certainly the fact that Charles was the one proposing the change
carried additional weight for me due to his past work on Policy.

It's probably also worth noting that I have a somewhat different approach
on how fast to commit changes.  I'm a huge believer in lazy consensus and
in the power of reverts, so I tend towards committing things and reverting
them if needed, rather than waiting on the first commit.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #642 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@debian.org>

To: 741573@bugs.debian.org

Cc: Sam Hartman <hartmans@debian.org>, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Mon, 20 Jul 2015 21:50:21 +0200

On Monday 20 July 2015 17:14:03 Josselin Mouette wrote:
> Bill used his position as a policy editor to reject a change, not
> because it was against consensus or against the policy process, but
> because it was against his own opinion. Not as policy editor, but as
> menu maintainer.
> 
> This is the root of the problem. By asking whether the policy process
> has been respected, you are reversing the responsibility. It was Bill’s
> responsibility from day one to recuse himself from policy decisions on
> the menu.
> It was also Bill’s responsibility, from day one, to raise his own
> concerns to the policy change being discussed, not to rely on other
> people’s nitpicks *after* the new policy had been approved and
> committed.
> 
> Maybe, after all, this issue should not have been sent to the TC but to
> the DPL, to ask for the revocation of the abused delegation.

Seconded.

The debian menu is de facto dead; it is time to put it out of its misery.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Message #647 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: 741573@bugs.debian.org, Sam Hartman <hartmans@debian.org>, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Mon, 20 Jul 2015 22:42:41 +0200

On Mon, Jul 20, 2015 at 09:50:21PM +0200, Sune Vuorela wrote:
> The debian menu is de facto dead; it is time to put it out of its misery.

This kind of language while customary of Sune and Josselin is inappropriate and
rude to any people that have investigated significant time in maintaining menu.
Though I strongly suggest that Sune and Josselin be ignored, since anyway they have both
clearly stated that they were ignored the menu policy anyway, so they have no interest in
the outcome.

If we really want to improve communication on our list, the TC should start by 
rejecting rude statements and offensive referrals.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #652 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 741573@bugs.debian.org

Cc: Sam Hartman <hartmans@debian.org>, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Tue, 21 Jul 2015 08:26:42 +0200

Le lundi 20 juillet 2015 à 22:42 +0200, Bill Allombert a écrit :
> This kind of language while customary of Sune and Josselin is inappropriate and
> rude to any people that have investigated significant time in maintaining menu.

Before complaining about the rudeness of other people’s language, maybe
you should reflect on your own behavior, which is way more offensive
than any kind of swearing.

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Message #657 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: 741573@bugs.debian.org

Cc: debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Tue, 21 Jul 2015 05:06:05 -0400

>>>>> "Josselin" == Josselin Mouette <joss@debian.org> writes:

    Josselin> Sam Hartman <hartmans@debian.org> wrote: Bill, in his role
    Josselin> of policy editor said that he believed there was not a
    Josselin> consensus.  He cited a specific set of messages that he
    Josselin> believes were not properly addressed.

    >> From the beginning, I have been puzzled by your approach to this
    >> issue.
    Josselin> With this paragraph, I think I’m beginning to understand
    Josselin> how you want to treat the issue. And I can’t say I think
    Josselin> it is constructive.

    Josselin> Bill used his position as a policy editor to reject a
    Josselin> change, not because it was against consensus or against
    Josselin> the policy process, but because it was against his own
    Josselin> opinion. Not as policy editor, but as menu maintainer.

First, I definitely understand your frustration with the process.  It
 sounds like you expect to have confidence that policy
 editors  follow the community's needs and do not allow their personal
 biases to influence their decisions.  It sounds like you're frustrated
 because you don't see that happening here.

I strongly value building robust processes.  When we treat matters as
confrontations between people, we build frustration, we drive people
away, and we poison the atmosphere of the community.  However, it's also
important that we  address peoples frustrations.  I hope we can get to a
point where we all believe that if there were a similar issue in the
future, it would be resolved much more quickly.

We all have biases.  So, before focusing on blaming people or deciding
they are not acting in good faith, I'd like to focus on looking at what
we can do to have reasonable results even in the case of biases and bad
decisions from time to time.  I think we would all be less frustrated if this
issue had been quickly resolved in a couple of weeks even if Bill had
displayed some bias in his initial call.

When I read Bill's message, he was claiming to act as a policy editor
*not* as a menu maintainer.  So, yes I'll start by assuming that he is
doing what he said he's doing and discard that assumption very
reluctantly.

Now, does Bill have biases?
Almost certainly.
Bill did state his own objections early in the discussion; one of the
messages he pointed to that he claims was not addressed was his own
message.
Would bill have  focused so much on finding objections if he  didn't
dislike the proposal so much?  Probably not.  Would Bill have been more
willing to decide that objections were handled if he liked the proposal
better?  Many people would be more sympathetic to proposals they liked.

Should Bill have recused?
Your current process does not describe when policy editors should
recuse.
One thing we may learn here is that we need to be more clear about how
we handle recusals.

Again, my hope is that we can work on our processes and our
understanding of how we address issues like this.  I think that we could
get to a place where it takes a couple of weeks to resolve these sorts
of disagreements in most cases.
I think we can also do a better job of understanding what we expect.

However, I also recognize that it's possible we'll find ourselves in a
situation where a member of the community is not meeting the
expectations we've jointly agreed.  I think in such cases that the
discussion about that member should be with the DPL.
I also think separating the discussion of how to handle the issue from
discussions of specific members of the community is valuable.  As a TC
member I'm going to focus on the process and the specific technical
proposal, *not* on the personalities.

Message #662 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Bill Allombert <ballombe@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Russ's role

Date: Tue, 21 Jul 2015 05:07:50 -0400

>>>>> "Bill" == Bill Allombert <ballombe@debian.org> writes:

    Bill> On Mon, Jul 20, 2015 at 10:34:47AM -0400, Sam Hartman wrote:
    >> You said:
    >> Hi.  As a matter of fact finding.  Russ's message, which Charles
    >> sites implies to me that Russ was swamped and didn't have time to
    >> do the commit.  By seconding, he had already done the review.

    Bill> Seconding a bug does not imply doing a consensus search, even
    Bill> for a policy editor.

We are not in agreement on this issue.
I've quoted the text from your process document that explains people
seconding a proposal are expected to evaluate consensus as well as
evaluate the technical quality of the proposal.
I've also explained my review of whether that happened in this instance.

Message #667 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Wed, 22 Jul 2015 13:34:01 +0100

Sam Hartman writes ("Bug#741573: #741573: Menu Policy and Consensus"):
> In March of 2014, Charles Plessy asked the Debian Technical Committee to
> review one of the policy editors decisions to revert changes to how
> policy talks about the Debian Menu and MIME support.  See
> http://bugs.debian.org/741573 for the TC process and
> https://bugs.debian.org/707851.  for the process within debian-policy.

Hi.

I am concerned at the direction this conversation has gone in.

As you will know, I'm not really in favour of the TC dealing with this
issue by primarily looking at whether the policy process was followed.

There are two problems with that approach:


1. The TC - not the policy process, not the policy editors, and not
the consensus on debian-policy - has the ultimate responsibility to
set technical policy.  (Constitution 6.1(1))

So in the TC the question of whether the policy process was or was not
followed does not dispose of the question of what the policy text
should actually be.

It would therefore be quite wrong for the TC to confine itself to
discussions of whether the policy process was followed.  More so,
whether the policy process was followed is of no bearing when we afre
considering the technical and social merits of the competing options.

The TC should be looking at the merits of the competing options.


2. Discussions about whether someone did or did not follow a
documented process are often acrimonious.  Such conversations should
be avoided if they are not necessary for the decision at hand.


If there is a problem with people not being able to work together, or
a breakdown of trust, that is a matter for the DPL who appoints the
policy team.[1]


I am also once again disturbed to read messages from Bill's opponents
where they declare a system that Bill mostly maintains, and wants to
keep maintaining, "dead" and want to "kill" it.


[1] Personally I am doubtful that the DPL has the authority to appoint
the policy maintainers.  I think the policy maintainers are the
maintainers of a package and therefore the authority lies with the TC
under 6.1(2).

Bear in mind that debian-policy is not the only package containing
policy documents covered by 6.1(1).  Programming-language-specific
policies are often in the language packages; even parts of core policy
are sometimes in dpkg-dev or whereever.  However:

(a) it appears that my view on this point is a minority and not shared
in particular by the policy team, the Secretary, the DPL, or the TC,
so it is rather academic.

(b) if it /is/ the TC's responsibility, the question of who should be
the primary maintainer(s) of debian-policy is a separate question to
what the document should contain in this disputed case.

It would be perfectly consistent (for example) for the TC to conclude
that Alice was right on the substantive question (ie that policy ought
to say what Alice[2] wants it to say), but conclude that Alice's
interactions and ways of pursuing this legitimate objective were
sufficiently disruptive that trust has been lost and it would be
better for Alice to stop down as policy editor.


Ian.

[2] Alice chosen because we already have Bill (B) and Charles (C)...

Message #672 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Wed, 22 Jul 2015 09:01:11 -0400

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

    Ian> 1. The TC - not the policy process, not the policy editors, and
    Ian> not the consensus on debian-policy - has the ultimate
    Ian> responsibility to set technical policy.  (Constitution 6.1(1))

    Ian> So in the TC the question of whether the policy process was or
    Ian> was not followed does not dispose of the question of what the
    Ian> policy text should actually be.

We are in strong agreement on this point.

    Ian> It would therefore be quite wrong for the TC to confine itself
    Ian> to discussions of whether the policy process was followed.

Also agreed.

    Ian> 
    Ian> More so, whether the policy process was followed is of no
    Ian> bearing when we afre considering the technical and social
    Ian> merits of the competing options.

    Ian> The TC should be looking at the merits of the competing
    Ian> options.


I actually think that whether the process is followed has very strong
bearing when considering the social merits of the competing options.
We are a volunteer project.
We thrive when people feel their contributions are valued, when they
feel they can make a difference.
There is a significant cost to the project when we reject contributions
that people have spent a lot of time working on.  People tend to
question whether allocating their time on these activities is valuable,
tend to question whether the project's values are aligned with their
values.

So, between two reasonable technical options, choosing the one that
values the time and work people have put in serves a significant social
good that helps build and strengthen our community.

I  think that there is a huge social benefit to fairness.  I find that I
am more willing to spend energy on organizations where I have rescourse
if I believe that fairness of process has not been met.
So I think it's absolutely critical that there be a way you can get a
process decision reviewed.
We can debate whether the TC is the right place for that.  I'll note
that reviewing a consensus call/a consensus process requires deep
knowledge of the technical issues involved.  If you take a look at
documents like RFC 7282 that discuss what it means to have rough
consensus, you'll find they are filled with judgment calls about the
technical issues.  So whoever does review this sort of call needs to
have significant technical skill.


I also think process has technical bearing.  I value consensus-based
processes because I believe they tend to produce superior technical
results.  I think that debian-policy has a wider set of skills than the
TC, and the members contributing to the discussion on debian-policy have
spent more time understanding the issue than the current TC members
involved in this discussion.
If the TC found itself coming to a different conclusion than an informed
rough consensus of debian-policy, it should carefully consider whether
that is the right course.

However, I absol/absolutely agree that the TC is responsible for the
content of policy and we cannot (or at least should not) delegate that
responsibility.
Even if the TC finds that the process is followed, the TC must evaluate
whether it has any objections to the resulting policy.

I think the key area where we differ is that I would give preference
other things being mostly equal to  upholding the work done in
debian-policy.  As I understand it, you would vote for the option you
thought technically best.  I wouldn't do that because I think the social
costs are important and because I recognize a real chance I might be
technically wrong.

I do think the form of the question posed to the TC has some importance.
I would be thinking about this somewhat differently if someone had asked us to
review menu policy because they had specific technical concerns with the
policy that was adopted.

You note that discussions of whether someone followed a process tend to
be acromonious.  We're in agreement there.  I've been frustrated when
I've seen people making this about Bill or about Charles and whether
they abused rights/responsibility.

I've tried to be careful to make this be about the process and not to
judge specific members of the community.  I'd be really happy if others
would join me in that.

My experience is that having discussions about process tends and whether
it is followed in specific cases tends to allow you to better understand
your requirements and understand gaps in shared expectations.
I find that  tends over time to significantly remove acromony.  As an
exampleI tend to feel a sense of relief that replaces frustration when I
understand that the reason someone isn't doing what I want is that they
have different expectations.  We can get down to the business of seeing
if there are mutually compatible expectations to be had.
It's quite obvious to me that Bill and Charles have different
expectations here, and I think there's significant acromony that can be
avoided if the community is able to clarify which expectations we as a
community hold.

Message #677 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Wed, 22 Jul 2015 16:03:23 +0100

Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and Consensus"):
> If the TC found itself coming to a different conclusion than an informed
> rough consensus of debian-policy, it should carefully consider whether
> that is the right course.

I have a very different view.  The membership of the policy mailing
list is very self-selecting, and not necessarily selecting for the
properties we would want.

For example, people interested in getting involved in debian-policy
are likely to have a disposition towards trying to make things
uniform, rather than towards valuing diversity.  They are also likely
to have a disposition towards contributing by discussing rather than
by coding.  Discussions (and thereview the view of "consensus") are
easily dominated by those who have much time and many opinions.

> I think the key area where we differ is that I would give preference
> other things being mostly equal to  upholding the work done in
> debian-policy.  As I understand it, you would vote for the option you
> thought technically best.  I wouldn't do that because I think the social
> costs are important and because I recognize a real chance I might be
> technically wrong.

I'm not sure precisely what social costs you are referring to.

Perhaps you mean disappointment on the part of people who have spent
effort to build consensus in debian-policy in order to make progress
in a controversial area.  But if there are serious objections, which a
participant wishes to take to the TC, it seems to me that such a
consensus (if it exists) has probably been achieved by wearing down
the sceptics rather than by convincing them (or perhaps by the absence
of the opponents to begin with).

Or perhaps you mean disappointment on the part of the policy editors.
But the policy editors have adopted[1] a system led by process rather
than own judgement.  The policy process avoids the policy editors
making the primary judgements on proposals and thus becoming invested
in them.  You would be suggesting that the TC should perhaps avoid
overturning a decision reached via the policy process, on the grounds
that this might upset the policy maintainers.  That would mean that
no-one would actually be taking responsibility for the content of the
decision!


To put it another way: the policy editors have cast themselves as
referees, not judges or designers.  For the TC to do the same would
mean that - when the question is controversial and has a strong
political element - the actual decision would be simply be based on
which side has the most effort and best tactics in a mailing list
flamewar.

Not only does that result in bad decisions, but it rewards behaviours
which are effective at generating apparent consensus on mailing lists.
I'm sure it will be obvious to you that there are many behaviours
which are very effective for that but which are also very harmful
(indeed, which work _because_ they are harmful).  In Debian we
normally mitigate this problem by arranging that someone or some group
is in charge of the decision and applies their own judgement.


Finally (and at the risk of sounding like one of those people who
quote the Social Contract at every opportunity) I would like to point
out that your view seems contrary to the spirit of the Constitution.

The Constitution does of course say `may', so the TC isn't required to
determine the content of policy.  But that is just the language used
when determining the powers abnd responsibilities of every
constitutionally defined role.

Ian.

[1] Note that there is nothing saying that the policy editors have to
do things this way.  When I wrote and edited the policy manual I did
so according to my best judgement.

Message #682 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Wed, 22 Jul 2015 11:39:45 -0400

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

    Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and
    >> I think the key area where we differ is that I would give
    >> preference other things being mostly equal to upholding the work
    >> done in debian-policy.  As I understand it, you would vote for
    >> the option you thought technically best.  I wouldn't do that
    >> because I think the social costs are important and because I
    >> recognize a real chance I might be technically wrong.

    Ian> I'm not sure precisely what social costs you are referring to.

    Ian> Perhaps you mean disappointment on the part of people who have
    Ian> spent effort to build consensus in debian-policy in order to
    Ian> make progress in a controversial area.  But if there are
    Ian> serious objections, which a participant wishes to take to the
    Ian> TC, it seems to me that such a consensus (if it exists) has
    Ian> probably been achieved by wearing down the sceptics rather than
    Ian> by convincing them (or perhaps by the absence of the opponents
    Ian> to begin with).

Having such serious objections that have not been adequately considered
means you don't have rough consensus at least in the ways I judge rough
consensus.
It was perhaps not obvious in some of my mail, but  I did:

* evaluate each objection Bill raised in his mail where he reverted the
  change to see if I thought it was addressed at a process level.

* Evaluate each of those objections as a TC member to see if I thought
  it was in my technical judgment a problem with the proposal.

* Try to explain the objections to the rest of the TC so they could make
  their evaluation using their technical judgment (including pointers if
  they want to  dig more deeply)

Doing all of those are important to me.

With regard to the current issue it's my opinion that we have no serious
issues that have not been considered.  It's my opinion that in my
technical judgment I'm comfortable with the resolution to the issues
that were considered.
If you or anyone else wants me to look at some specific issue either
from a process standpoint or to make a judgment about whether I think
the resolution is reasonable, please start another thread on the bug.
If I have not already voted I'll do so.

I'm still in the process of doing my own technical evaluation of the
proposal to see if I come up with any technical objections I consider
serious enough to raise.  It'll be awkward from a TC internal process
standpoint if I do because the ballot is frozen at this point, but I've
completed enough of my evaluation that I don't anticipate any such
objections.  I'll be done before I vote and will definitely be able to
complete within the voting period even if Don calls for a vote now.


    Ian> Or perhaps you mean disappointment on the part of the policy
    Ian> editors.  

I do not.  Your reasons are somewhat similar to mine.



    Ian> To put it another way: the policy editors have cast themselves
    Ian> as referees, not judges or designers.  

Agreed to some extent.  The policy editors do have some role as
consensus judges, but to a large extent they have delegated that to
those seconding proposals according to their process document.  In
practice, I suspect they do a fair bit of consensus judging themselves.


    Ian> For the TC to do the
    Ian> same would mean that - when the question is controversial and
    Ian> has a strong political element - the actual decision would be
    Ian> simply be based on which side has the most effort and best
    Ian> tactics in a mailing list flamewar.

I would urge you to read RFC 7282.  I understand this is not the IETF
and even the IETF has not chosen to bind itself to that document.
However it displays some of the level of thought required in judging
rough consensus.
A judge of consensus is very much responsible for thinking about the
technical issues and making sure they have adequately been considered.
A judge of consensus is very much responsible for making sure the
process does not turn into who-shouts-loudest.

Someone reviewing a consensus process probably isn't in a position to
fix a process where participants were driven away in frustration
(silencing their objections) but should detect this sort of thing and
claim the process failed to reach consensus when significant viewpoints
were excluded.

However, I think the TC has very important roles beyond just judging
consensus.
We need to decide what the policy is.  We can and in my opinion should
factor in the opinions of others in doing that.

As a practical matter the debian-policy list does a lot of that.
When debian-policy properly takes up an issueit's important to me that
the TC value the work they have done.  Part of that to me is that we
should have a reason for deciding differently.

I'd also be fine adjusting how much policy work is done by debian-policy
and how much is done by the TC.  There's a constitutional limit of
course in that the tc cannot come up with the proposals itself (although
members can be part of that).
I won't drive such an effort, but if you think that we'd get better
policy by changing the policy process such that when there is
contraversy the proposals are tossed up to the TC to decide between,
then I urge you to build support for your view and see if you can get
the debian-policy process changed, or to work at the debian-project
level to build support for a different role for debian-policy.


    Ian> Not only does [allowing the decision to be about who shouts loudest] result in bad decisions, but it rewards
    Ian> behaviours which are effective at generating apparent consensus
    Ian> on mailing lists.  I'm sure it will be obvious to you that
    Ian> there are many behaviours which are very effective for that but
    Ian> which are also very harmful (indeed, which work _because_ they
    Ian> are harmful).  In Debian we normally mitigate this problem by
    Ian> arranging that someone or some group is in charge of the
    Ian> decision and applies their own judgement.

I believe that's the TC's job.

I'd like to try and characterize areas where we disagree because I think
it will help us understand each other and give others something to think
about.  In my previous mail I said:
Sam> I think the key area where we differ is that I would give preference
Sam> other things being mostly equal to  upholding the work done in
Sam> debian-policy.  As I understand it, you would vote for the option you
Sam> thought technically best.  

You didn't confirm this, but it still sounds from what you've said  like
that would be a fair summary.  I'm not trying to put words in your
mouth, just confirm my understanding of your position.
Additionally, it sounds like one of the reasons why may be that you're
more skeptical of the technical quality of debian-policy than I am.

    Ian> Finally (and at the risk of sounding like one of those people
    Ian> who quote the Social Contract at every opportunity) I would
    Ian> like to point out that your view seems contrary to the spirit
    Ian> of the Constitution.

    Ian> The Constitution does of course say `may', so the TC isn't
    Ian> required to determine the content of policy.  But that is just
    Ian> the language used when determining the powers abnd
    Ian> responsibilities of every constitutionally defined role.

I think my job as a TC member is to come up with the best technical
policy for Debian I can.  I think we disagree on how to accomplish that.

Message #687 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: 741573@bugs.debian.org, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Thu, 23 Jul 2015 08:45:53 +0200

[Message part 1 (text/plain, inline)]

Hi Sam,

[side note: while I joined the original discussion, I don't really have
a stake in the outcome, other than the desire to have a working menu]

On Tue, Jul 21, 2015 at 09:06:08AM +0000, Sam Hartman wrote:
> Should Bill have recused?
> Your current process does not describe when policy editors should
> recuse.
> One thing we may learn here is that we need to be more clear about how
> we handle recusals.

I'm not sure if the lack of a policy on recusals is a good excuse for
the failure to do so. If Bill opposed the proposal (which certainly is
his right), he *should* have actively partaken in the discussion,
pointing out *why* he thought it a bad idea and asking for
clarifications, improvements, etc. Instead, he mostly ignored the
discussion while it was happening (not counting the occasional mails
pointing out what he believed to be inaccuracies), and only making fully
clear that he was going to oppose the proposal when he reverted the
commit that implemented what others thought to be consensus.

I don't think this is appropriate for anyone, regardless of whether
they're policy editors. If you have an objection to a technical change
in Debian, historically we've always required that people come up with
technical reasons for either supporting or objecting to, the change.
Bill did not do that, at least not to the level I would expect from
someone who opposes a proposed change that seems to be building
consensus.

Anyway.

While I applaud your attempts to get the original people around the
table again, I'm not sure that's either productive or the role of the
TC. Not productive, because I feel that the different parties have
pretty much reached set positions that they're extremely unlikely to
deviate from anymore; and not the role of the TC, because it is the
technical committee's role to take *technical* decisions, which this
approach would not necessarily lead to.

Instead, I would prefer if the technical committee would, after
reviewing the arguments pro and con, take a decision on *which menu
system* to move forward with, rather than trying to fix the original
discussion, for which I have little hope that it will be successful.

I do believe Charles' original mail was a request for the TC to do so.
If it isn't in your interpretation, please consider this an official
request in that manner.

Thanks,

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

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

[signature.asc (application/pgp-signature, inline)]

Message #692 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>

To: Wouter Verhelst <wouter@debian.org>

Cc: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Thu, 23 Jul 2015 14:12:31 +0200

On Thu, Jul 23, 2015 at 08:45:53AM +0200, Wouter Verhelst wrote:
> Hi Sam,
> 
> [side note: while I joined the original discussion, I don't really have
> a stake in the outcome, other than the desire to have a working menu]
> 
> On Tue, Jul 21, 2015 at 09:06:08AM +0000, Sam Hartman wrote:
> > Should Bill have recused?
> > Your current process does not describe when policy editors should
> > recuse.
> > One thing we may learn here is that we need to be more clear about how
> > we handle recusals.
> 
> I'm not sure if the lack of a policy on recusals is a good excuse for
> the failure to do so. If Bill opposed the proposal (which certainly is
> his right), he *should* have actively partaken in the discussion,
> pointing out *why* he thought it a bad idea and asking for
> clarifications, improvements, etc. Instead, he mostly ignored the
> discussion while it was happening (not counting the occasional mails
> pointing out what he believed to be inaccuracies), and only making fully
> clear that he was going to oppose the proposal when he reverted the
> commit that implemented what others thought to be consensus.

This is not the case. I made my position clear the first time in the bug log,
but one year later Charles decided to restart the discussion while ignoring all
that was previously said. That made me angry and I have a policy not to post
when I am angry.

Charles write with the undertone that his position will carry the day and that
naysayer are a minority, which I find displeasing, especially when aiming for
consensus, going as far as 'apologizing' to peope wanting to continue to support
Debian menu.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #697 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Thu, 23 Jul 2015 22:55:55 +0900

Le Thu, Jul 23, 2015 at 02:12:31PM +0200, Bill Allombert a écrit :
> 
> This is not the case. I made my position clear the first time in the bug log,
> but one year later Charles decided to restart the discussion while ignoring all
> that was previously said. That made me angry and I have a policy not to post
> when I am angry.
> 
> Charles write with the undertone that his position will carry the day and that
> naysayer are a minority, which I find displeasing, especially when aiming for
> consensus, going as far as 'apologizing' to peope wanting to continue to support
> Debian menu.

Bill, you are the only person complaining, and your position is not clear.

The original request is to "soften the wording recommending menu files" and
everybody except you agrees to do so.

The wording has been made without your input, because you did not participate
constructively to that part of the discussion.  You only were throwing in
vague arguments and taking other people as strawmen.

I made efforts to keep the wording mild, but I think that it was an error.
From your attiude as the lead person behind the Debian Menu, it is clear that
it has no future.  For one decade, you have taken no leadership to build this
future.  As a consequence, I think that the next step is to plan its
replacement and deprecation.  Maybe the TC will come to this conclusion.

Cheers,

-- 
Charles

Message #702 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: 741573@bugs.debian.org, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Fri, 24 Jul 2015 08:57:27 -0400

>>>>> "Charles" == Charles Plessy <plessy@debian.org> writes:

    Charles> I made efforts to keep the wording mild, but I think that
    Charles> it was an error.
    >> From your attiude as the lead person behind the Debian Menu, it
    >> is clear that
    Charles> it has no future.  For one decade, you have taken no
    Charles> leadership to build this future.  As a consequence, I think
    Charles> that the next step is to plan its replacement and
    Charles> deprecation.  Maybe the TC will come to this conclusion.

That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.

Message #707 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Sam Hartman <hartmans@debian.org>, 741573@bugs.debian.org

Cc: Charles Plessy <plessy@debian.org>, debian-policy@lists.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Fri, 24 Jul 2015 16:20:52 +0200

Sam Hartman <hartmans@debian.org> wrote: 
        That seems very unlikely to me.  Diversity is an important part of
        Debian.  I think it is likely that the TC is going to value the Debian
        Menu as long as Bill or someone else is going to work on it.  I would
        expect us to value the menu enough to enable those who want to
        contribute to it to do so.

Given the state menu is in, reading this is… flabbergasting, to say the
least. I would answer tons of things, but fortunately they have already
been put together concisely: http://islinuxaboutchoice.com/ 

        I think that's consistent with the consensus proposal that you asked us
        to consider in this bug.

The consensus proposal was, in order to preserve some bits of Bill’s
ego, to let menu die slowly by stopping to require mandatory entries for
a useless menu system that only a handful of obscure window managers are
still able to display. Now that Bill has made very clear, by completely
giving in to ridicule, that his ego should not be a problem, Charles is
merely proposing to accelerate that process and avoid pain for everyone.

-- 
Joss

Message #712 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Mon, 27 Jul 2015 15:05:03 -0700

On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette <joss@debian.org> wrote:
> Sam Hartman <hartmans@debian.org> wrote: 
>         That seems very unlikely to me.  Diversity is an important part of
>         Debian.  I think it is likely that the TC is going to value the Debian
>         Menu as long as Bill or someone else is going to work on it.  I would
>         expect us to value the menu enough to enable those who want to
>         contribute to it to do so.
> 
> Given the state menu is in, reading this is… flabbergasting, to say the
> least. I would answer tons of things, but fortunately they have already
> been put together concisely: http://islinuxaboutchoice.com/ 
> 
>         I think that's consistent with the consensus proposal that you asked us
>         to consider in this bug.
> 
> The consensus proposal was, in order to preserve some bits of Bill's
> ego, to let menu die slowly by stopping to require mandatory entries for
> a useless menu system that only a handful of obscure window managers are
> still able to display. Now that Bill has made very clear, by completely
> giving in to ridicule, that his ego should not be a problem, Charles is
> merely proposing to accelerate that process and avoid pain for everyone.

Josselin, do you really believe that an inflamatory message like this is
the right way to get your point across and get people to agree with you?

While I agree with the underlying arguments you're referring to, both
about "choice" and about the (lack of) value of the old menu system,
this kind of mail doesn't help anyone get past this issue, nor does it
come across as reasonable.  It's worth noting that the old menu system
provided a significant amount of value for many years, long before the
XDG menu existed.  That it no longer holds as much importants as it once
did is no reason to denigrate people involved with it.

- Josh Triplett

Message #717 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Mon, 27 Jul 2015 15:45:15 -0700

On Mon, 27 Jul 2015 15:05:03 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
> On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette <joss@debian.org> wrote:
> > Sam Hartman <hartmans@debian.org> wrote: 
> >         That seems very unlikely to me.  Diversity is an important part of
> >         Debian.  I think it is likely that the TC is going to value the Debian
> >         Menu as long as Bill or someone else is going to work on it.  I would
> >         expect us to value the menu enough to enable those who want to
> >         contribute to it to do so.
> > 
> > Given the state menu is in, reading this is… flabbergasting, to say the
> > least. I would answer tons of things, but fortunately they have already
> > been put together concisely: http://islinuxaboutchoice.com/ 
> > 
> >         I think that's consistent with the consensus proposal that you asked us
> >         to consider in this bug.
> > 
> > The consensus proposal was, in order to preserve some bits of Bill's
> > ego, to let menu die slowly by stopping to require mandatory entries for
> > a useless menu system that only a handful of obscure window managers are
> > still able to display. Now that Bill has made very clear, by completely
> > giving in to ridicule, that his ego should not be a problem, Charles is
> > merely proposing to accelerate that process and avoid pain for everyone.
> 
> Josselin, do you really believe that an inflammatory message like this is
> the right way to get your point across and get people to agree with you?
> 
> While I agree with the underlying arguments you're referring to, both
> about "choice" and about the (lack of) value of the old menu system,
> this kind of mail doesn't help anyone get past this issue, nor does it
> come across as reasonable.  It's worth noting that the old menu system
> provided a significant amount of value for many years, long before the
> XDG menu existed.  That it no longer holds as much importants as it once

s/importants/importance/; half-finished edit.

> did is no reason to denigrate people involved with it.
> 
> - Josh Triplett
> 
> 

Message #722 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 741573@bugs.debian.org

Subject: Proposed draft of ballot to resolve menu/desktop question

Date: Wed, 29 Jul 2015 07:59:53 -0700

I'm proposing the following draft ballot to resolve the menu/desktop
question. This draft is available in git; feel free to make specific
changes there and announce them to the bug. If there is no discussion or
substantial changes to this draft, I will call for votes around Monday
the 3rd of August. If there is discussion or changes, I will delay as
appropriate.



Whereas:
       
   1. The Debian Technical Committee has been asked to resolve a
      dispute between maintainers of Debian Policy over a change that

      i. incorporates the description of the FreeDesktop menu system
         and its use in Debian for listing program in desktop menus
         and associating them with media types

     ii. softens the wording on the Debian Menu system to reflect that
         in Jessie it will be neither displayed nor installed by
         default on standard Debian installations.

 Using its power under §6.1.1 to decide matters of technical policy:

OPTION A:

   1. The Technical Committee adopts the changes proposed by Charles
      Plessy in ba679bff[1].

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

[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
      Debian menu package support translating .desktop files of
      packages which do not provide menu files.


OPTION B:
   1. Considers that the policy procedure resulted in consensus, and
      adopts the changes proposed by Charles Plessy in ba67bff.[1]

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

[1]: http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

OPTION C:

  1. The Technical Committee adopts the changes proposed by Bill
     Allombert.[1]

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

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=patch2;bug=707851;msg=446

OPTION Z:

Further discussion


-- 
Don Armstrong                      http://www.donarmstrong.com

The attackers hadn't simply robbed the bank. They had carried off
everything portable, including the security cameras, the carpets, the
chairs, and the light and plumbing fixtures. The conspirators had
deliberately punished the bank, for reasons best known to themselves,
or to their unknown controllers. They had superglued doors and
shattered windows, severed power and communications cables, poured
stinking toxins into the wallspaces, and concreted all of the sinks
and drains. In eight minutes, sixty people had ruined the building so
thoroughly that it had to be condemned and later demolished.
 -- Bruce Sterling, _Distraction_ p4

Message #727 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Don Armstrong <don@debian.org>

Cc: 741573@bugs.debian.org

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

Date: Wed, 29 Jul 2015 11:11:13 -0400

Unless someone objects
I propose that the following text also be included in option b:

Using its power under §6.1.5 to offer advice:

   1. The Technical Committee suggests that the maintainers of the
      Debian menu package support translating .desktop files of
      packages which do not provide menu files.


I'd like to be able to vote on that option, but I suspect there's no one
who favors B who doesn't favor that text.

Message #732 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 741573@bugs.debian.org

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

Date: Wed, 29 Jul 2015 10:29:10 -0500

On Wed, 29 Jul 2015, Sam Hartman wrote:
> Unless someone objects
> I propose that the following text also be included in option b:
> 
> Using its power under §6.1.5 to offer advice:
> 
>    1. The Technical Committee suggests that the maintainers of the
>       Debian menu package support translating .desktop files of
>       packages which do not provide menu files.
> 
> 
> I'd like to be able to vote on that option, but I suspect there's no one
> who favors B who doesn't favor that text.

Sounds good to me; added.

-- 
Don Armstrong                      http://www.donarmstrong.com

Junkies were all knitted together in a loose global macrame, the
intercontinental freemasonry of narcotics.
 -- Bruce Sterling, _Holy Fire_ p257

Message #737 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 741573@bugs.debian.org

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

Date: Sun, 16 Aug 2015 15:02:45 +0200

[Message part 1 (text/plain, inline)]

Le mercredi, 29 juillet 2015, 10.29:10 Don Armstrong a écrit :
> On Wed, 29 Jul 2015, Sam Hartman wrote:
> > Unless someone objects
> > I propose that the following text also be included in option b:
> > 
> > Using its power under §6.1.5 to offer advice:
> >    1. The Technical Committee suggests that the maintainers of the
> >    
> >       Debian menu package support translating .desktop files of
> >       packages which do not provide menu files.
> > 
> > I'd like to be able to vote on that option, but I suspect there's no
> > one who favors B who doesn't favor that text.
> 
> Sounds good to me; added.

Are we somehow stuck on this issue?

I unfortunately missed yesterday's TC BoF @DebConf, but what I got from 
the video and re-reading the last meetings' minutes (which I also 
missed, bummer), it appears to me that we have a "orientation" conflict, 
which I'll try to phrase as I understand it:

The current ballot [dla_draft.txt] focuses on deciding between two 
outcomes of the policy process (AB vs C), with two "flavours" (A vs B) 
to actually let us decide whether to explicitely say that we consider 
that the process reached consensus. I understand this ballot as the 
result of the TC (arguably pushed in this direction by some of its fresh 
members) re-focusing the issue on the process question, rather than the 
technical question. As I undertand it, Steve is unhappy with this 
ballot.

On the other hand, we have Keith's proposal [keithp_draft.txt] that 
explicitely doesn't address the "process question", but comes with an 
explicit technical decision (roughly saying "where a 'menu' entry was 
needed, this should be a .desktop; 'menu' should use .desktop"). As I 
understand the situation, Sam is unhappy with this ballot.

So, how do we move forward with this? I've personally put some thought 
to this issue, have re-read all drafts, and, although I very much 
appreciate Sam's approach and agree with his "consensus achievement" 
conclusions, I now think that Keith's proposal is technically an "even 
better" solution than the original "consensually achieved" solution. 
That said, picking Keith's option doesn't let us (modulo new amendments) 
explicitely give our opinion on how the process worked, but I'm starting 
to think that this might be a good thing, in the end.

What about "just" adding Keith's proposal to the ballot, and let the 
Condorcet magic act?

Cheers,
OdyX

[dla_draft.txt]		http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/dla_draft.txt
[keithp_draft.txt]	http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/keithp_draft.txt

[signature.asc (application/pgp-signature, inline)]

Message #742 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 741573@bugs.debian.org

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

Date: Sun, 16 Aug 2015 07:33:49 -0700

On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote:
> What about "just" adding Keith's proposal to the ballot, and let the
> Condorcet magic act?

This has sort of been my plan; I just have not had enough spare cycles
in the past few weeks (grant deadlines) to have the time necessary to
work through Keith's plan and shift it into a specific patch to policy.

If someone else wants to take this on and run with it, I'd appreciate
that. Otherwise, I'll hopefully get to it in the next two weeks.

-- 
Don Armstrong                      http://www.donarmstrong.com

For a moment, nothing happened. Then, after a second or so, nothing
continued to happen.
 -- Douglas Adams

Message #747 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 741573@bugs.debian.org

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

Date: Sun, 16 Aug 2015 17:54:50 +0200

[Message part 1 (text/plain, inline)]

Le dimanche, 16 août 2015, 07.33:49 Don Armstrong a écrit :
> On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote:
> > What about "just" adding Keith's proposal to the ballot, and let the
> > Condorcet magic act?
> 
> This has sort of been my plan; I just have not had enough spare cycles
> in the past few weeks (grant deadlines) to have the time necessary to
> work through Keith's plan and shift it into a specific patch to
> policy.
> 
> If someone else wants to take this on and run with it, I'd appreciate
> that. Otherwise, I'll hopefully get to it in the next two weeks.

I've committed the attached draft that keeps ABC+Z options from your 
draft, adds Keith's as option D (but without the "information addition", 
that we might want to keep in mind (website, post to debian-policy if 
that becomes the decision, etc), but that I don't really see as part of 
our decision.

That said, re-checking the Constitution, I'm only uneasy with how 
Keith's proposal is to be understood under §6.3.5 "No detailed design 
work".

Is this ballot something we could proceed with?

Cheers,
OdyX

[odyx_draft.txt (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #752 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Don Armstrong <don@debian.org>

Cc: 741573@bugs.debian.org

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

Date: Mon, 17 Aug 2015 08:18:01 -0400

>>>>> "Don" == Don Armstrong <don@debian.org> writes:

    Don> On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote:
    >> What about "just" adding Keith's proposal to the ballot, and let
    >> the Condorcet magic act?

    Don> This has sort of been my plan; I just have not had enough spare
    Don> cycles in the past few weeks (grant deadlines) to have the time
    Don> necessary to work through Keith's plan and shift it into a
    Don> specific patch to policy.

If you add Keith's proposal as well as an explanation of our technical
objection to what debian-policy came up with it, I might even vote for
it.

If you were to add a recommendation to ballot option B that under 6.1.5
we ask debian-policy to consider Keith's proposal, I'd prefer that to
the current text.

If you simply add a ballot option for Keith's proposal without text in
the decision explaining our technical objection to option A/B, I'll
disagree with it as strongly as I can.  (Read, I'd probably feel
strongly enough to fight the issue in other fora if I was in the rough
here).
While we're not overturning anything in the sense of an override here, I
think we owe an explanation for our actions, and I feel really strongly
about that.

Message #757 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org

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

Date: Mon, 17 Aug 2015 21:25:59 +0900

Le Sun, Aug 16, 2015 at 05:54:50PM +0200, Didier 'OdyX' Raboud a écrit :
> 
>    3. We recommend that the maintainers of the 'menu' package update
>       that package to reflect this increased focus on .desktop files
>       by modifying the 'menu' package to use .desktop files for the
>       source of menu information in addition to menu files.

Hi Didier and everybody,

I think that option D has two fundamental flaws and I would like to recommend
the TC against voting for it.

* First, if it is voted, nothing will happen.

If the TC adopts option D, and if the maintainer (no plural) of the 'menu'
package decides to not follow point 3's recommendation, what will be the
practical difference between option D and option Z ?  I voiced this concern in
2014 (741573#450), but got no answer.  Who do you expect to do the work ?

The reason I ask is that option D carries nothing new.  In 2008, we already
had a discussion which outcome was very similar to what is proposed in option D.

    https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

Nothing happened in 5 years, in my opinion because a) the Debian menu system
is written in C, which does not help for attracting propositions of patches,
and b) its maintainer is obviously hostile to change.

* Second, it does not solve the problem that I sumbitted to the TC.

See in particular Josselin's objection in 741573#405 and Keith's answer:

Josselin:

   "One of the problems I have with your proposal, compared to Charles’ original
   patch, is that it encourages maintainers of hundreds of (IMHO useless) menu
   files to port them to the desktop format."

Keith:

    Yeah, there are a lot of inappropriate entries in my /usr/share/menu
    directory. Can we fix policy to weed these out? The current
    wording in §9.6:

          All packages that provide applications that need not be passed any
          special command line arguments for normal operations should
          register a menu entry for those applications.
    
    seems problematic to me -- it seems to require menu entries for things
    as diverse as a web browser and a python interpreter. Coming up with
    wording that encourages only programs which are conventionally used in
    interactive mode to be included seems like a good fix here.

Option D exactly brings use back to the original problem, without solving it !
Please remember that the title of the bug where the dispute stems is : "soften
the wording recommending menu files".  In that sense, the format of the menu
files does not matter.  What Bill opposes with his trench war and delay tactics
is the modification of §9.6 above.  Option D does not contain such a change.

What will happen if option D is voted ?  Nothing.  In 2008, the popcon vote
score of the menu package was around 35 %, in 2014 around 25 % and now in 2015
it is around 15 %.  And much of it may be just because of its dpkg trigger.  If
the TC votes option D, I will be disappointed but rest assured that the issue
will not come back to the TC later again: the Debian menu will dissapear
eventually by itself.

The problem here is our inability to face the facts and accept to change the
Policy to fit the reality.  This is what I asked the TC for.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #762 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: Charles Plessy <plessy@debian.org>, 741573@bugs.debian.org

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

Date: Mon, 17 Aug 2015 18:14:45 +0200

[Message part 1 (text/plain, inline)]

Hi Charles, and thanks for your feedback,

Le lundi, 17 août 2015, 21.25:59 Charles Plessy a écrit :
> I think that option D has two fundamental flaws and I would like to
> recommend the TC against voting for it.
> 
> * First, if it is voted, nothing will happen.
> 
> If the TC adopts option D, and if the maintainer (no plural) of the
> 'menu' package decides to not follow point 3's recommendation, what
> will be the practical difference between option D and option Z ?

I disagree with this, because of the last sentence of D1, put in force 
using §6.1.1 (decide on any matter of technical policy): "Applications 
providing a .desktop file should not provide a Debian menu file." This 
will allow maintainers that _do_ provide .desktop files to stop 
providing .menu files as well.

> I voiced this concern in 2014 (741573#450), but got no answer.  Who do
> you expect to do the work ?

Either the 'menu' maintainer and/or anyone sufficiently interested in 
keeping said system relevant. With D1 in place, I expect .menu files to 
start disappearing from the archive at a good pace; it will become 
somewhat urgent for those relying on the menu system to work towards 
having this .desktop-to-menu translation infrastructure in place.

> The reason I ask is that option D carries nothing new.  In 2008, we
> already had a discussion which outcome was very similar to what is
> proposed in option D.
> 
>     https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

I think it is quite reasonable to assume that Keith's proposal is a 
derivative of that proposal.

> * Second, it does not solve the problem that I sumbitted to the TC.

The TC is currently trying to decide whether to decide on the conflict 
(AB vs C) or to decide on the 'menu' matter of technical policy (D).

I honestly think all 4 options would resolve the "unresolvable conflict" 
that you referred to the TC.

> See in particular Josselin's objection in 741573#405 and Keith's
> answer:
>
> > One of the problems I have with your proposal, compared to
> > Charles’ original patch, is that it encourages maintainers of
> > hundreds of (IMHO useless) menu files to port them to the desktop
> > format.

I agree that the current proposition doesn't address this problem in D1, 
in that it says:
> packages for which the Debian menu system currently applies should
> provide a .desktop file

One key word is "currently" in there. I think it is reasonable to read 
this as "run 's/register a menu entry/provide a FreeDesktop .desktop 
file/g' over Policy §9.6". It would certainly not prevent further 
changes to §9.6 as long as the TC decision is respected.

From what I understand of your opposition, you're afraid that further 
discussions around softening the "all packages that provide applications 
that need not be passed any special command line arguments for normal 
operation should provide a FreeDesktop .desktop file entry for those 
application" part would be met with unresolvable opposition from Bill, 
right? What about the following formulation then (not yet entirely 
convinced, but I hope that's a step forward)?

>   1. The Technical Committee resolves that applications providing a
>      .desktop file should not provide a Debian menu file.

This would delegate the decision on which applications are supposed to 
provide a .desktop file to (arguably yet another) the Debian Policy 
process.

Cheers,
OdyX

[signature.asc (application/pgp-signature, inline)]

Message #767 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 741573@bugs.debian.org

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

Date: Tue, 18 Aug 2015 22:15:41 +0900

Le Mon, Aug 17, 2015 at 06:14:45PM +0200, Didier 'OdyX' Raboud a écrit :
> Hi Charles, and thanks for your feedback,

Thanks as well for your prompt answer :)  Here are a few point-to-point
comments.  Altogether, I would happily support option D if it were further
amended.

> the last sentence of D1, put in force 
> using §6.1.1 (decide on any matter of technical policy): "Applications 
> providing a .desktop file should not provide a Debian menu file." This 
> will allow maintainers that _do_ provide .desktop files to stop 
> providing .menu files as well.

Indeed, I have overlooked that important part.  Sorry for this.
 
> With D1 in place, I expect .menu files to 
> start disappearing from the archive at a good pace; it will become 
> somewhat urgent for those relying on the menu system to work towards 
> having this .desktop-to-menu translation infrastructure in place.

An alternative would be to develop support for the FreeDesktop menu on those
platforms that only have the Debian menu at the moment.

Since option D is calling for volunteer work, which may be quite unusual for
the TC, I think that it would be important that it either provides alternatives
like the one above, or explain briefly why they were not retained in the final
resolution.
 
> >     https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries
> 
> I think it is quite reasonable to assume that Keith's proposal is a 
> derivative of that proposal.

Thanks.  I would appreciate if it would be acknowledged, I am a bit academic by
training...

> The TC is currently trying to decide whether to decide on the conflict 
> (AB vs C) or to decide on the 'menu' matter of technical policy (D).

In my impression, it is not a good thing to conflate two different kind of
decisions in the same vote.  This said, the current portfolio of options is a
good ground for focusing on the technical aspects.

C: Status quo reaffirming the wording of the Policy and the importance of
   the Debian Menu (needed even for the Python interpreter, etc).

Z: Status quo by inaction.

AB: Softening the requirement of the Debian Menu.

D: Migration to the FreeDesktop format, and therefore disparition of the Debian
   Menu if nobody works on this migration.

(By the way, I am not sure how to interpret the difference between A and B.)

I have invested a lot of time on AB as I was looking for a compromise that
would satisfy broady, but as I wrote more recently, I also do not mind a more
radical outcome.  I would support option D it if we resolve the the point
below.

> From what I understand of your opposition, you're afraid that further 
> discussions around softening the "all packages that provide applications 
> that need not be passed any special command line arguments for normal 
> operation should provide a FreeDesktop .desktop file entry for those 
> application" part would be met with unresolvable opposition from Bill, 
> right? What about the following formulation then (not yet entirely 
> convinced, but I hope that's a step forward)?
> 
> >   1. The Technical Committee resolves that applications providing a
> >      .desktop file should not provide a Debian menu file.

This is the first half of solving the problem.  The second would be to add that
the "should" requirement of the Policy's section 9.6, paragraph 2, is changed
to "may".

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #772 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: 741573@bugs.debian.org

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

Date: Tue, 18 Aug 2015 14:01:27 -0500

On Mon, 17 Aug 2015, Sam Hartman wrote:
> >>>>> "Don" == Don Armstrong <don@debian.org> writes:
> 
>     Don> On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote:
>     >> What about "just" adding Keith's proposal to the ballot, and let
>     >> the Condorcet magic act?
> 
>     Don> This has sort of been my plan; I just have not had enough spare
>     Don> cycles in the past few weeks (grant deadlines) to have the time
>     Don> necessary to work through Keith's plan and shift it into a
>     Don> specific patch to policy.
> 
> If you add Keith's proposal as well as an explanation of our technical
> objection to what debian-policy came up with it, I might even vote for
> it.

This is my plan. The proposal needs to be written up as a specific patch
to policy, with a separate rationale, and then we can actually vote on
it as a separate option in the ballot.

I'm trying to find some spare cycles to work on this in the next two
weeks, but if someone beats me to it, excellent.

> If you were to add a recommendation to ballot option B that under
> 6.1.5 we ask debian-policy to consider Keith's proposal, I'd prefer
> that to the current text.

If no one gets around to handling the above, that might be what we have
to do.

[...]

> While we're not overturning anything in the sense of an override here,
> I think we owe an explanation for our actions, and I feel really
> strongly about that.

Ideally the patch and its rationale should stand alone without the need
for a separate text. But that said, if you disagree that the rationale
is not sufficient once it exists, I'll either try to modify it or draft
a separate text.

-- 
Don Armstrong                      http://www.donarmstrong.com

I don't care how poor and inefficient a little country is; they like
to run their own business.  I know men that would make my wife a
better husband than I am; but, darn it, I'm not going to give her to
'em.
 -- The Best of Will Rogers

Message #777 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 741573@bugs.debian.org

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

Date: Tue, 18 Aug 2015 21:23:26 +0200

Le mardi, 18 août 2015, 14.01:27 Don Armstrong a écrit :
> On Mon, 17 Aug 2015, Sam Hartman wrote:
> > >>>>> "Don" == Don Armstrong <don@debian.org> writes:
> >     Don> On Sun, 16 Aug 2015, Didier 'OdyX' Raboud wrote:
> >     >> What about "just" adding Keith's proposal to the ballot, and
> >     >> let
> >     >> the Condorcet magic act?
> >     
> >     Don> This has sort of been my plan; I just have not had enough
> >     spare
> >     Don> cycles in the past few weeks (grant deadlines) to have the
> >     time
> >     Don> necessary to work through Keith's plan and shift it into a
> >     Don> specific patch to policy.
> > 
> > If you add Keith's proposal as well as an explanation of our
> > technical objection to what debian-policy came up with it, I might
> > even vote for it.
> 
> This is my plan. The proposal needs to be written up as a specific
> patch to policy, with a separate rationale, and then we can actually
> vote on it as a separate option in the ballot.

I'm not convinced: I see Keith's proposal as "TC setting technical 
policy without actually phrasing the detailed patch for the Debian 
Policy document" as a fine course of action for us to take. Actually, 
I'm afraid that crafting the detailed Policy patch would put the 
concerned sections of Policy under some sort of "TC dome", which I don't 
see as a desirable outcome.

Formulated differently, I prefer deciding on a technical _choice_ rather 
than a detailed Policy patch. ABC options are to be seen differently, as 
they are pre-existing Debian Policy patches. Finally, I really have a 
hard time seeing how crafting a Debian Policy patch ourselves doesn't 
fall under §6.3.5 "no detailed design work - The TC does not engage in 
design of new (…) policies", whereas Keith's proposal is more clearly 	
§6.1.1 "decide of any matter of technical policy".

Cheers,
OdyX

Message #782 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Don Armstrong <don@debian.org>

Cc: 741573@bugs.debian.org

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

Date: Wed, 19 Aug 2015 10:57:43 -0400

>>>>> "Don" == Don Armstrong <don@debian.org> writes:

    >> While we're not overturning anything in the sense of an override
    >> here, I think we owe an explanation for our actions, and I feel
    >> really strongly about that.

    Don> Ideally the patch and its rationale should stand alone without
    Don> the need for a separate text. But that said, if you disagree
    Don> that the rationale is not sufficient once it exists, I'll
    Don> either try to modify it or draft a separate text.

No, a rationale that explains why option D is better than A/B is all I'm
asking for.

Message #787 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@debian.org>

To: Sam Hartman <hartmans@debian.org>

Cc: Don Armstrong <don@debian.org>, 741573@bugs.debian.org

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

Date: Wed, 19 Aug 2015 17:24:12 +0200

On Wednesday 19 August 2015 10:57:43 Sam Hartman wrote:
> >>>>> "Don" == Don Armstrong <don@debian.org> writes:
>     >> While we're not overturning anything in the sense of an override
>     >> here, I think we owe an explanation for our actions, and I feel
>     >> really strongly about that.
> 
>     Don> Ideally the patch and its rationale should stand alone without
>     Don> the need for a separate text. But that said, if you disagree
>     Don> that the rationale is not sufficient once it exists, I'll
>     Don> either try to modify it or draft a separate text.
> 
> No, a rationale that explains why option D is better than A/B is all I'm
> asking for.

From my technical POV I think Option D is better than A/B because it is a more 
clear technical solution, and saying "there is one menu to care about"

The current A/B thing ended up as a standard compromise that tries to leave 
everyone equally unhappy, and ending everyone having to decide for them selves 
which menus to cater for.

I don't think A/B is a particular good solution but is immensely better than 
doing nothing. Option D is what I was hoping for we would end up with in some 
years after letting the debian menu bitrot for another couple of years.

In option D4, I'd though like if "Debian Desktop" or similar was involved, as 
it is likely the debian desktop maintainers (XFCE, Plasma, Gnome, LX(DE|Qt), 
..) who are closest to the users in this regard.

From my social POV I'd love to see B win because I really think that there was 
a good enough consensus to be able to move on with issues like that. If we 
hadn't had the double-role of menu maintainer and policy editor, I'm pretty 
sure we wouldn't have gotten here in the first place.

But as Debian is a technical project consisting of social individuals, I would 
hope to see D>B>A>Z>C as the final result.

/Sune
 - the one who initiated this mess

Message #792 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

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

Date: Thu, 27 Aug 2015 18:11:56 +0100

Responding mostly to Keith's draft from debian-ctte.git.


The Whereas leaves out a very important aspect of this.  It is not
sufficient to simply decide on the file format.  The primary dispute
here is not really about file formats.

The trad Debian menu is primarily curated collection of metadata,
reified as entries in individual packages' desktop files.

The trad Debian menu, and the XDG menu files as found in existing
desktop applications, do not agree on either (i) the scope of the menu
(ii) the categorisation of those applications which do appear in the
menu (iii) sometimes, the proper description of those applications.
(Let us assume for the sake of argument that there are few intentional
differences in icons.)

Indeed (ii) and (iii) follow from (i).


So the real dispute is: should the existing application metadata
database (currently represented by the Debian trad menu files in
existing packages):

 (a) continue to be maintained in its existing file format

 (b) be translated to a new and more modern file format
     (perhaps only for some packages)

 (c) be destroyed.

Given that there are people who want to maintain it, I think (c) is
unacceptable.[1]


Ian.

Message #797 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

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

Date: Thu, 27 Aug 2015 18:14:08 +0100

I had an interesting and helpful conversation with a member of the KDE
team at Debconf.  They made an interesting proposal:

 * We have machinery that can produce trad menu files from desktop
   files.

 * It is possible to have extension information in extra fields in a
   .desktop file.  This could be used to record the trad Debian
   category and name metadata currently residing in trad Debian menu
   files.

 * Where such metadata is accepted by upstream, we could include it in
   the primary .desktop file.

 * Where such metadata is not accepted by upstream, our tooling could
   be arranged to be able to combine XDG information from two .desktop
   files, one from upstream and one provided in the Debian package.
   This would avoid the need for patching an upstream menu file, which
   is unattractive.

 * Overall, this would make it possible, therefore, to maintain the
   menu information primarily in the more sophisticated .desktop
   format, so that source packages with .desktop files would not need
   to contain trad menu files too.

The only remaining questions are then :

 Q1.  Whether it is better to convert from .desktop files to trad
      Debian menu files at package build time, or to change the
      existing trad menu consumers to be able to convert .desktop
      files to the required format ?

      There is an easy answer to this: this conversion may involve
      image conversion libraries including even perhaps an SVG
      renderer, and other conversion software, which is
      disproportionately heavyweight for many trad menu consumers.
      (Trad menu consumers tend to be non-desktop `lightweight' window
      managers.)

      Whereas most software that ships a .desktop file will have
      fairly extensive build dependencies, and in general adding image
      conversion tools to their build dependencies will not be
      awkward.  This also means the conversion is done once, at
      package build, rather than on each end-user system.

      Therefore the format specified in the .deb, to be used by trad
      menu consumers should continue to be the trad Debian menu file.

 Q2.  Whether packages (bc, many command line games, ...) which only
      want to provide a trad Debian menu entry should do so by
      including a .desktop file in the source code, or a trad menu
      entry.

      I see no need for policy to mandate any particular answer to
      this.  The maintainer should do what they prefer.

Ian.

Message #802 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 741573@bugs.debian.org

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

Date: Thu, 27 Aug 2015 20:37:21 +0200

Le jeudi, 27 août 2015, 18.11:56 Ian Jackson a écrit :
> The trad Debian menu, and the XDG menu files as found in existing
> desktop applications, do not agree on either
> (i) the scope of the menu

Right. But the 'trad Debian menu' (as outlined in Policy §9.6) has never 
reached the point where "applications that need not be passed any 
special command line arguments for normal operation" have a menu entry.

I think this never happened mostly because having that metadata is plain 
useless for vast amounts of "applications" we have under {/usr},/bin. 
The other reason is also that the XDG menu has been adopted by most 
major desktop environments, and is perceived as vastly more useful 
(multiple sized icons, translation, etc).

Finally, my /usr/share/menu/ has _89_ entries, where I have 419 .desktop 
entries under /usr/share/applications (for 4325 installed packages, and 
4214 executables in /usr/bin). So, as of today, this part of policy is 
de facto _not_ followed.

> So the real dispute is: should the existing application metadata
> database (currently represented by the Debian trad menu files in
> existing packages)

I disagree that this is the real dispute: today, the trad Debian menu 
application metadata database is de facto already of less relevance than 
the (not-in-policy) the XDG Menu, by orders of magnitude.

>  (a) continue to be maintained in its existing file format
> 
>  (b) be translated to a new and more modern file format
>      (perhaps only for some packages)
> 
>  (c) be destroyed.
> 
> Given that there are people who want to maintain it, I think (c) is
> unacceptable.

Keith's proposal doesn't imply that the trad menu would "be destroyed" 
(your words), but would indeed imply that the trad menu system would 
need to make use of the de-facto more relevant XDG Menu. If there are 
_enough_ people that use the trad Debian menu system, I am confident 
that this _will_ happen.

On the other hand, if there are not enough users and maintainers for the 
trad menu, I do find it unacceptable to further impose on all 
maintainers (through a Policy "should") the burden of maintaining this 
redundant metadata database, which is nowadays _de_facto_ replaced by 
the technically superior XDG Menu.

I think phrasing the question in terms of "there is this existing 
database, how should it be transformed" is misleading, whereas I see the 
question as "which metadata databases make sense for the future of 
Debian".

Cheers,
OdyX

Message #807 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Didier 'OdyX' Raboud <odyx@debian.org>, 741573@bugs.debian.org

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

Date: Fri, 28 Aug 2015 13:51:52 +0100

Didier 'OdyX' Raboud writes ("Bug#741573: Proposed draft of ballot to resolve menu/desktop question"):
> Right. But the 'trad Debian menu' (as outlined in Policy §9.6) has never 
> reached the point where "applications that need not be passed any 
> special command line arguments for normal operation" have a menu entry.

I'm not sure why you think this is relevant.

Policy says every command line program should have a manpage, but we
have many many command line programs without.  That a project's
coverage isn't complete is not a reason to throw it away.

> I disagree that this is the real dispute: today, the trad Debian menu 
> application metadata database is de facto already of less relevance than 
> the (not-in-policy) the XDG Menu, by orders of magnitude.

I don't understand why you think that something being of `less
relevance' means it should be destroyed.

> >  (a) continue to be maintained in its existing file format
> > 
> >  (b) be translated to a new and more modern file format
> >      (perhaps only for some packages)
> > 
> >  (c) be destroyed.
> > 
> > Given that there are people who want to maintain it, I think (c) is
> > unacceptable.
> 
> Keith's proposal doesn't imply that the trad menu would "be destroyed" 
> (your words),

It does.  There is nothing in Keith's proposal which preserves the
existing trad menu metadata.  According to `apt-file search' that is a
database of 2296 menu entries (in wheezy).

> On the other hand, if there are not enough users and maintainers for the 
> trad menu, I do find it unacceptable to further impose on all 
> maintainers (through a Policy "should") the burden of maintaining this 
> redundant metadata database, which is nowadays _de_facto_ replaced by 
> the technically superior XDG Menu.

The XDG menu database does not contain a menu entry for many things
that the trad menu does.  And this is intentional.  So it is not a
replacement.

Ian.

Message #812 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@mit.edu>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 741573@bugs.debian.org, Didier 'OdyX' Raboud <odyx@debian.org>

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

Date: Fri, 28 Aug 2015 09:13:33 -0400

Ian, I'd like to encourage you to use less loaded words than "destroy."
When I hear that term and disagree with your analysis, my emotional
reaction is strong enough that I stop reading.
Your term is loaded enough that you lose the opportunity to try and get
me to think about whether you are right.
If your goal is to ask us to think about your position and engage in
reasoned discourse, you would be better served with more factual, less
emotional statements.
I understand that the emotional content is important too.  I'd recommend
carrying that by talking about your own emotional state rather than
using emotional words about the concept.
For example when I heard you describe that you were so upset you needed
to leave the conversation at Debconf, I heard someone being open and
honest about how much they care about the issue.

I think I may be following what Ian's saying.


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.

We're leaving the specifics to the individual maintainers.  However, I
can see that if you value the scope of the trad menu, you'd be really
frustrated by that  decision.

Message #817 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@debian.org>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Fri, 28 Aug 2015 14:22:02 +0100

Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and Consensus"):
> Having such serious objections that have not been adequately considered
> means you don't have rough consensus at least in the ways I judge rough
> consensus.

Thanks for your thoughtful response and care when reading.

However, I'm afraid I think this is rather muddled thinking.
Consensus is a question about what proprtion of people hold certain
opinion.  It doesn't involve a value judgement.  Whereas, `adequately
considered' involves a value judgement.

>     Ian> For the TC to do the
>     Ian> same would mean that - when the question is controversial and
>     Ian> has a strong political element - the actual decision would be
>     Ian> simply be based on which side has the most effort and best
>     Ian> tactics in a mailing list flamewar.
> 
> I would urge you to read RFC 7282.  I understand this is not the IETF
> and even the IETF has not chosen to bind itself to that document.

I see references to the IETF as a repeated theme in your writings on
these subjuects.

I'm sorry to say that the I think the IETF is a poor model for
technical decisionmaking.  Indeed output from the IETF in many areas
has indeed suffered from precisely the kind of problems that one would
expect from an institution dominated by the people who have time and
willingness to argue on mailing lists. [1]

It may be difficult for the IETF to do better (because better
approaches may not scale well).

But Debian has a robust governance system and is small enough that we
can have difficult technical decisions made by a panel of highly
competent people - and that's what the TC is supposed to be.


So:

> However, I think the TC has very important roles beyond just judging
> consensus.

I think, in general, it should be no part of the TC's role to judge
consensus.  (There may be exceptions.)

Privileging consensus encourages all sorts of very dysfunctional
behaviours.  It encourages browbeating; wearing down of the
opposition; canvassing for supporters to come and join the fight;
asking the same question again; misrepresentation of others' views;
mailing list archeaology; arguments about who said what when; etc.

All of these are to a greater or lesser extent toxic.

> We need to decide what the policy is.  We can and in my opinion should
> factor in the opinions of others in doing that.

I certainly agree that the TC should take into account the opinions of
others.  But those opinions should be tested and evaluated on their
merits.

> Sam> I think the key area where we differ is that I would give preference
> Sam> other things being mostly equal to  upholding the work done in
> Sam> debian-policy.  As I understand it, you would vote for the option you
> Sam> thought technically best.  
> 
> You didn't confirm this, but it still sounds from what you've said  like
> that would be a fair summary.  I'm not trying to put words in your
> mouth, just confirm my understanding of your position.
> Additionally, it sounds like one of the reasons why may be that you're
> more skeptical of the technical quality of debian-policy than I am.

I'm sorry to say that I have very little confidence in the
debian-policy /process/, where it comes to controversial or difficult
questions.  This is not to say that I lack confidence in the policy
/editors/; in fact, I would like the policy /editors/ to use a process
which relies /more/ on their own judgement.

The current policy process works fine for easy questions - but for
easy questions, any process will do.

In practice, where technically complex questions are successfuly
resolved, this is usually done by the relevant experts communicating
elsewhere until they reach agreement, and then perhaps, or perhaps
not, writing up their conclusions as policy changes.

It is natural that policy will act as a lightning rod for
disagreement.  I think this is inevitable.  But at the moment, the
policy process is ill set up for dealing with such questions.


So with the policy process as currently constituted, and because I
think consensus is such a poor guide, I think that the TC should not
be heavily influenced by the outcome of the policy process.

If the policy editors were prepared to take a more definite line
themselves, and apply their own judgement, then the situation would be
very different.  But in that situation I think that for entirely
different reasons, the TC ought not to defer to the policy editors.

So either way, I think when it is deciding policy, the TC ought to be
making up its own mind on the merits.


> I think my job as a TC member is to come up with the best technical
> policy for Debian I can.  I think we disagree on how to accomplish that.

Yes.

Ian.


[1] Examples of IETF-generated nonsense that I'm aware of:
* A6, DNAME, bitstring labels; now thankfully (mostly) abandonded
* Unconsidered breakage of DNS round robin load balancing
* IPv6 SLAAC vs DHCPv6
* Indeed much of the new IPv6 architecture is clearly contrary to
  the intent of the IESG decision selecting IPv6
* DNSSEC, whose first iteration was undeployable
* Recent NNTP/Usenet RFCs
* Curve25519 - PinkBikeshed vs PurpleBikeshed vs ...

Message #822 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 741573@bugs.debian.org

Subject: Re: Bug#741573: #741573: Menu Policy and Consensus

Date: Fri, 28 Aug 2015 09:33:48 -0400

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

    Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and
    Ian> Consensus"):
    >> Having such serious objections that have not been adequately
    >> considered means you don't have rough consensus at least in the
    >> ways I judge rough consensus.

    Ian> Thanks for your thoughtful response and care when reading.

    Ian> However, I'm afraid I think this is rather muddled thinking.
    Ian> Consensus is a question about what proprtion of people hold
    Ian> certain opinion.  It doesn't involve a value judgement.
    Ian> Whereas, `adequately considered' involves a value judgement.

Ah, yes, we do not agree on what consensus is.
I think I understand your position well at this point and I thank you
for sharinge.
While I think your view on what consensus is differs from the consensus
view of consensus, I can certainly see where you are coming from.

If there are areas where you think additional discussion would be
valuable, I'd be happy to engage.  For this point though, I think I
understand our disagreement, and while I respect  where you are coming
from I'll need to do what I think is best.

--Sam

Message #827 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@mit.edu>

Cc: 741573@bugs.debian.org, Didier 'OdyX' Raboud <odyx@debian.org>

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

Date: Fri, 28 Aug 2015 14:36:38 +0100

Sam Hartman writes ("Re: Bug#741573: Proposed draft of ballot to resolve menu/desktop question"):
> Ian, I'd like to encourage you to use less loaded words than
> "destroy."

I can see why you are objecting but I'm afraid I cannot see these
proposals any other way.  Perhaps as you suggest it would be more
politic (more effective) to object in weaker terms.

But frankly, I am absolutely livid.  It's quite an effort to write as
calmly as I am now doing.


> I think I may be following what Ian's saying.

I agree with what you say in this summary except that I would go
further:

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

The dominant interpretation of this proposal is that that this
information should simply be removed from Debian.

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

Worse than that, the TC would be saying that
 - the trad menu metadata database
 - currently in Debian [1]
 - which people have been working on for many years
 - and want to keep working on
should be deleted.

"Deleted" may be "emotionally loaded" too but it is of course 100%
technically accurate, because the TC would be saying that all records
in the trad menu database, which are reified as files in source
packages in our archive, should be deleted.  The files should be
deleted from the source packages and the information that was formerly
in those files would no longer appear in Debian.

I can't see a way in which that is anything but deletion, abolition,
destruction.

You may say that "destruction" has additional connotations of force,
violence, or disruption.  Well, see above: the people who maintain
this database want to keep it, and as you observe it will cause
disruption.

Ian.

[1] (if only partially present, perhaps in part because of vigorous
     campaigning saying it is obsolete and should be got rid of)

Message #832 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 741573@bugs.debian.org, "Didier 'OdyX' Raboud" <odyx@debian.org>

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

Date: Fri, 28 Aug 2015 09:44:27 -0400

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Hi.
I'd appreciate it if you would look at the restatement at the bottom and
help me make sure I'm understanding the technical implications of the
proposal we're considering.

    >> I think I may be following what Ian's saying.

    Ian> I agree with what you say in this summary except that I would
    Ian> go further:

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

    Ian> The dominant interpretation of this proposal is that that this
    Ian> information should simply be removed from Debian.

That doesn't make sense to me.
Without an update to section 9.6, we're saying that we agree with the
trad menu's scope, but want the data represented in .desktop files.

I personally think that would be bad technically, but I don't see how
you get from that to "delete".  You might get quickly to "the TC is
spewing nonsense because a bunch of interface work needs to be done to
make what they've asked us to do possible."
However I consider that different from "delete"

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

    Ian> Worse than that, the TC would be saying that - the trad menu
    Ian> metadata database - currently in Debian [1] - which people have
    Ian> been working on for many years - and want to keep working on
    Ian> should be deleted.

I don't think so.
I think we'd be saying that people should evaluate each trad menu entry
against the newly revised 9.6 and if the package maintainer believed the
information  was worth keeping then it should be converted to .desktop.

I don't think you'd be happy with that result, but I think that is what
we'd be saying with Keith's draft including the section 9.6 update.

Some information would be deleted; we'd be updating the scope.
However other information would be converted.

I'm not trying to argue emotional loading here.  I honestly want to know
if I'm missing something here and whether more is deleted than I expect.

Message #837 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Sam Hartman <hartmans@debian.org>

Cc: 741573@bugs.debian.org, "Didier 'OdyX' Raboud" <odyx@debian.org>

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

Date: Fri, 28 Aug 2015 14:56:01 +0100

Sam Hartman writes ("Re: Bug#741573: Proposed draft of ballot to resolve menu/desktop question"):
> I'd appreciate it if you would look at the restatement at the bottom and
> help me make sure I'm understanding the technical implications of the
> proposal we're considering.
...
> That doesn't make sense to me.
> Without an update to section 9.6, we're saying that we agree with the
> trad menu's scope, but want the data represented in .desktop files.

In part, sorry, I have misunderstood.  I read you as writing "_with_"
an update to 9.6.

But even reading what you wrote (sorry) it's not just a question of
scope.

It's also categorisation.  The .desktop files and the menu files have
different taxonomy and I think in some cases different labelling.  If
the TC says, without saying anything else, that .desktop files should
be used, maintainers will discard the taxonomy and labelling in the
menu files in favour of that already present in .desktop files.

Also, consider a maintainer of a package which currenly only has a
menu file, who is trying to conform to the new scheme.  They will
probably think they are supposed to discard the menu file taxonomy in
favour of asking desktop environment teams about the proper DE
taxonomy of their program.  This isn't going to work well if the DE
teams think the program shouldn't have a menu item.  What is the
maintainer of `bc' supposed to do ?

> I personally think that would be bad technically, but I don't see how
> you get from that to "delete".  You might get quickly to "the TC is
> spewing nonsense because a bunch of interface work needs to be done to
> make what they've asked us to do possible."
> However I consider that different from "delete"

This is of course another objection.

I don't think a policy update to say "use desktop files" without
specifying specific fields is a sensible idea.  Perhaps the TC could
ask someone to write such a thing by saying in general terms what was
wanted.

Ian.

Message #842 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 741573@bugs.debian.org

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

Date: Fri, 28 Aug 2015 15:10:40 +0100

I realise that it was perhaps a tactical error to send both
(a) a message with impassioned rhetoric and (b) a message containing
constructive proposal.

Let me repost the proposal with some extra commentary:

Ian Jackson writes:
> I had an interesting and helpful conversation with a member of the KDE
> team at Debconf.  They made an interesting proposal:
> 
>  * We have machinery that can produce trad menu files from desktop
>    files.
> 
>  * It is possible to have extension information in extra fields in a
>    .desktop file.  This could be used to record the trad Debian
>    category and name metadata currently residing in trad Debian menu
>    files.
> 
>  * Where such metadata is accepted by upstream, we could include it in
>    the primary .desktop file.
> 
>  * Where such metadata is not accepted by upstream, our tooling could
>    be arranged to be able to combine XDG information from two .desktop
>    files, one from upstream and one provided in the Debian package.
>    This would avoid the need for patching an upstream menu file, which
>    is unattractive.
> 
>  * Overall, this would make it possible, therefore, to maintain the
>    menu information primarily in the more sophisticated .desktop
>    format, so that source packages with .desktop files would not need
>    to contain trad menu files too.
> 
> The only remaining questions are then :
> 
>  Q1.  Whether it is better to convert from .desktop files to trad
>       Debian menu files at package build time, or to change the
>       existing trad menu consumers to be able to convert .desktop
>       files to the required format ?
> 
>       There is an easy answer to this: this conversion may involve
>       image conversion libraries including even perhaps an SVG
>       renderer, and other conversion software, which is
>       disproportionately heavyweight for many trad menu consumers.
>       (Trad menu consumers tend to be non-desktop `lightweight' window
>       managers.)
> 
>       Whereas most software that ships a .desktop file will have
>       fairly extensive build dependencies, and in general adding image
>       conversion tools to their build dependencies will not be
>       awkward.  This also means the conversion is done once, at
>       package build, rather than on each end-user system.
> 
>       Therefore the format specified in the .deb, to be used by trad
>       menu consumers should continue to be the trad Debian menu file.
> 
>  Q2.  Whether packages (bc, many command line games, ...) which only
>       want to provide a trad Debian menu entry should do so by
>       including a .desktop file in the source code, or a trad menu
>       entry.
> 
>       I see no need for policy to mandate any particular answer to
>       this.  The maintainer should do what they prefer.

I think this would involve:

 - defining new field names for .desktop files to contain
   the trad menu metadata, as necessary.  I think we can safely
   call these fields X-Debian-* or X-Debian-Menu-* or something.

 - a small amount of work in the already-existing .desktop-to-menu
   conversion program

 - a policy draft explaining what should come out in the .deb, with
   some informative text explaining how to get this effect using only
   .desktop files (or perhaps simply giving references to the
   appropriate tool documentation)

 - policy should probably say that a contributor sending a trad menu
   patch for a program with a .desktop file should do so by sending
   a .desktop file patch, rather than a trad menu patch.

In the longer term:

 - Desktop program maintainers would get occasional patches to add
   trad menu metadata to their .desktop files.  The tooling would then
   do the right thing.  This is the only extra human work that those
   maintainers would have to do.

 - GUI program maintainers have a choice of whether to provide trad
   menu entries via this new mechanism or by providing a separate trad
   menu file.

 - Maintainers of non-GUI programs which don't want to be in the DE
   menus can continue to provide menu entries for the trad menu
   without needing to interact with the XDG menu system.

 - Trad menu consumers do not need to gain any heavyweight runtime
   dependencies.

 - It is still possible to make the trad menu visible in DEs using the
   existing technique.  When that is done there are a trad menu entry,
   and DE menu entry, for the same program, each categorised and
   labelled according to the corresponding menu scheme.

Ian.

Message #847 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: 741573@bugs.debian.org

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

Date: Fri, 28 Aug 2015 16:34:45 +0200

Ian Jackson <ijackson@chiark.greenend.org.uk> wrote: 
>  - defining new field names for .desktop files to contain
>    the trad menu metadata, as necessary.  I think we can safely
>    call these fields X-Debian-* or X-Debian-Menu-* or something.

What is the use case for these fields? 

>  - a small amount of work in the already-existing .desktop-to-menu
>    conversion program

Who cares? We can have much better than that and use the XDG
specification to its full extent: 
https://wiki.archlinux.org/index.php/Xdg-menu

>  - policy should probably say that a contributor sending a trad menu
>    patch for a program with a .desktop file should do so by sending
>    a .desktop file patch, rather than a trad menu patch.

Good. This way it can be ignored as well.

> In the longer term:
> 
>  - Desktop program maintainers would get occasional patches to add
>    trad menu metadata to their .desktop files.  The tooling would then
>    do the right thing.  This is the only extra human work that those
>    maintainers would have to do.

So you complain that dropping entirely the Debian menu (which is the
sensible thing to do) would get rid of a few thousands
mostly-boilerplate files, while we get rid of much more than that in
useless C code every other minor release, but suddenly giving extra work
to all maintainers of packages containing desktop entries is OK? 

Maybe some people need to get rid of that mentality where other people
have to do more work to comply with their twisted view of reality. 

>  - GUI program maintainers have a choice of whether to provide trad
>    menu entries via this new mechanism or by providing a separate trad
>    menu file.

Or to do nothing at all about the trad menu, which is the sensible thing
to do? 

>  - Maintainers of non-GUI programs which don't want to be in the DE
>    menus can continue to provide menu entries for the trad menu
>    without needing to interact with the XDG menu system.

Or they can provide entries with appropriate
NoDisplay/OnlyShowIn/NotShowIn fields, as described in Charles’ proposed
policy. 

>  - Trad menu consumers do not need to gain any heavyweight runtime
>    dependencies.

Neither do they need to by using xdg_menu.

>  - It is still possible to make the trad menu visible in DEs using the
>    existing technique.

No, it is not. Maybe in an alternative reality, but in Debian, KDE and
GNOME have both made this impossible, on purpose.

There is no use for the traditional Debian menu. It is deadweight
technology. Any effort invested in it is wasted. Get over it.

-- 
Joss 

Message #852 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>

To: Josselin Mouette <joss@debian.org>, 741573@bugs.debian.org

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

Date: Fri, 28 Aug 2015 09:47:13 -0500

On Fri, 28 Aug 2015, Josselin Mouette wrote:
> Maybe some people need to get rid of that mentality where other people
> have to do more work to comply with their twisted view of reality. 

Calling someone else's viewpoint twisted is needlessly inflammatory and
not acceptable when discussing bugs which have been referred to the
CTTE. Please stop.


-- 
Don Armstrong                      http://www.donarmstrong.com

With one simple pill
we cured unhappiness
and art
 -- a softer world #437
    http://www.asofterworld.com/index.php?id=437

Message #857 received at 741573@bugs.debian.org (full text, mbox, reply):

From: Didier 'OdyX' Raboud <odyx@debian.org>

To: 741573@bugs.debian.org

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

Date: Fri, 28 Aug 2015 16:06:45 +0200