subject:"Bug#741573\: Two menu systems"

Ian Jackson ijack...@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.pack...@intel.com


pgpgA31zu9kfp.pgp
Description: PGP signature

Bug#741573: Two menu systems

Ian Jackson ijack...@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

Bug#741573: Two menu systems

Colin Watson cjwat...@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.pack...@intel.com


pgpfkt8fo4aqZ.pgp
Description: PGP signature

Bug#741573: Two menu systems

2014-06-30 Thread Josselin Mouette

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
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1404164217.14436.476.camel@dsp0698014

Bug#741573: Two menu systems

Russ Allbery r...@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.pack...@intel.com


pgpLYZ7LgSb_i.pgp
Description: PGP signature

Bug#741573: Two menu systems

Josselin Mouette j...@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.pack...@intel.com


pgpmwHwIldT7h.pgp
Description: PGP signature

Bug#741573: Two menu systems

2014-06-30 Thread Nikolaus Rath

Keith Packard kei...@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
   deb...@pusling.com. It was modified by Adam D. Barratt
   a...@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 deb...@pusling.com with modifications by Adam D. Barratt
   a...@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.«


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a98t1zej@vostro.rath.org

Bug#741573: Two menu systems

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

 Keith Packard kei...@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.pack...@intel.com


pgpp8TjiS5W0L.pgp
Description: PGP signature

Bug#741573: Two menu systems

2014-06-28 Thread Charles Plessy

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 22times;22 size, and preferably up to 64times;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
+ emhicolor/em icon theme directories, or to use an existing
+ icon from the emhicolor/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
+ ttNoDisplay/tt key to vartrue/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
+ emdebian-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 ttNotShowIn/tt/ttOnlyShowIn/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 ttmenu/tt package
- will automatically get menu entries in their window
- managers, as well in shells like ttpdmenu/tt.
/p

p
- The menu policy can be found in the ttmenu-policy/tt
- files in the ttdebian-policy/tt package.
- It is also available from the Debian web mirrors at
- tturl name=/doc/packaging-manuals/menu-policy/
-
id=http://www.debian.org/doc/packaging-manuals/menu-policy/;/tt.
/p

- p
- Please also refer to the emDebian Menu System/em
- documentation that comes with the packagemenu/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
+ emDebian menu/em file, following the emDebian menu policy/em,
+ which can be found in the ttmenu-policy/tt files in the
+ ttdebian-policy/tt package. It is also available from the Debian
+ web mirrors at tturl 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

--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140629013046.ga21...@falafel.plessy.net

Bug#741573: Two menu systems

2014-06-27 Thread Cameron Norman

On Thursday, June 26, 2014, Colin Watson cjwat...@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

Bug#741573: Two menu systems

2014-06-26 Thread Ian Jackson

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

Bug#741573: Two menu systems

2014-06-26 Thread Colin Watson

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   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140626173154.ga1...@riva.ucam.org

Bug#741573: Two menu systems

2014-06-26 Thread Russ Allbery

(Sorry I missed the meeting today.  I'm away on vacation and my schedule
ended up not aligning properly.)

Colin Watson cjwat...@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 (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhsjczm1@windlord.stanford.edu

Bug#741573: Two menu systems

2014-05-22 Thread Ian Jackson

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21374.2655.810674.651...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-05-11 Thread Russ Allbery

Anthony Towns a...@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

Bug#741573: Two menu systems

2014-04-14 Thread Jonathan Nieder

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140414175143.ga15...@google.com

Bug#741573: Two menu systems

2014-04-14 Thread Russ Allbery

Jonathan Nieder jrnie...@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 (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ob0378pv@windlord.stanford.edu

Bug#741573: Two menu systems

2014-04-13 Thread Anthony Towns

On 12 April 2014 05:32, Russ Allbery r...@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

Bug#741573: Two menu systems

2014-04-13 Thread Jonathan Nieder

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140414023845.ga17...@google.com

Bug#741573: Two menu systems

2014-04-12 Thread Ian Jackson

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21321.35358.178803.427...@chiark.greenend.org.uk

Bug#741573: Two menu systems

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21319.51727.219029.523...@chiark.greenend.org.uk

Bug#741573: Two menu systems

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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21319.52268.148420.980...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-11 Thread Sam Hartman

 Steve == Steve Langasek vor...@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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslbnw8jare@mit.edu

Bug#741573: Two menu systems

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21319.60311.971288.946...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-11 Thread Stuart Prescott

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 shoulds 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 Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201404112334.11730.stu...@debian.org

Bug#741573: Two menu systems

2014-04-11 Thread Sam Hartman

 Ian == Ian Jackson ijack...@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


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslwqewhtwr@mit.edu

Bug#741573: Two menu systems

2014-04-11 Thread Lisandro Damián Nicanor Pérez Meyer

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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

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.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21320.1481.566729.455...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-11 Thread Lisandro Damián Nicanor Pérez Meyer

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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

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.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21320.9581.906848.231...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-11 Thread Lisandro Damián Nicanor Pérez Meyer

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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

2014-04-11 Thread Russ Allbery

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 (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppknhdb0@windlord.stanford.edu

Bug#741573: Two menu systems

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.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21318.29964.866568.125...@chiark.greenend.org.uk

Bug#741573: Two menu systems

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.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21318.34053.670405.356...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-10 Thread Ansgar Burchardt

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53468a49.30...@debian.org

Bug#741573: Two menu systems

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21318.36277.694862.415...@chiark.greenend.org.uk

Bug#741573: Two menu systems

Ian Jackson ijack...@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 (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wqexwe2n@windlord.stanford.edu

Bug#741573: Two menu systems

Charles Plessy ple...@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 (r...@debian.org)   http://www.eyrie.org/~eagle/


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87siplwdzt@windlord.stanford.edu

Bug#741573: Two menu systems

Russ Allbery writes (Bug#741573: Two menu systems):
 Charles Plessy ple...@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.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21318.38437.78701.849...@chiark.greenend.org.uk

Bug#741573: Two menu systems

Russ Allbery writes (Bug#741573: Two menu systems):
 Ian Jackson ijack...@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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21318.38723.798731.65...@chiark.greenend.org.uk

Bug#741573: Two menu systems

Ian Jackson ijack...@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 (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877g6xz3ru@windlord.stanford.edu

Bug#741573: Two menu systems

Russ Allbery writes (Bug#741573: Two menu systems):
 Ian Jackson ijack...@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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21318.46470.871039.646...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-10 Thread Bdale Garbee

Ian Jackson ijack...@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


pgpuu2v0yIb3a.pgp
Description: PGP signature

Bug#741573: Two menu systems

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21318.54295.587035.465...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-10 Thread Sune Vuorela

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


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1641684.ANP4CvevnD@dabney

Bug#741573: Two menu systems

Ian Jackson ijack...@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 (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2gp58e4@windlord.stanford.edu

Bug#741573: Two menu systems

2014-04-10 Thread Lisandro Damián Nicanor Pérez Meyer

On Thursday 10 April 2014 09:38:28 Bdale Garbee wrote:
 Ian Jackson ijack...@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-...@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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

2014-04-10 Thread Steve Langasek

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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#741573: Two menu systems

Steve Langasek vor...@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 (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4zc3jix@windlord.stanford.edu

Bug#741573: Two menu systems

2014-04-10 Thread Stuart Prescott

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 
shoulds 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 Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534756ea.a642420a.1528.e...@mx.google.com

Bug#741573: Two menu systems

2014-04-10 Thread Lisandro Damián Nicanor Pérez Meyer

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
 shoulds 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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

2014-04-10 Thread Lisandro Damián Nicanor Pérez Meyer

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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21317.11576.830437.290...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-09 Thread Didier 'OdyX' Raboud

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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

2014-04-09 Thread Matthias Klumpp

2014-04-09 15:13 GMT+02:00 Didier 'OdyX' Raboud o...@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/

--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAKNHny_xCV2h_MvKjEETaSfZ0=v1jrqv8j7e1zyi0mnq8et...@mail.gmail.com

Bug#741573: Two menu systems

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.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21317.21132.22823.659...@chiark.greenend.org.uk

Bug#741573: Two menu systems

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.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21317.21364.82687.450...@chiark.greenend.org.uk

Bug#741573: Two menu systems

2014-04-09 Thread Lisandro Damián Nicanor Pérez Meyer

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
Description: This is a digitally signed message part.

Bug#741573: Two menu systems

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.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21317.51979.114443.457...@chiark.greenend.org.uk

Bug#741573: Two menu systems