Bug#741573: Two menu systems
On Mon, 22 Dec 2014 14:29:44 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: The traditional Debian menu system (mostly done by Bill Alombert) has been providing menu entries for bc and dc and everything for years. That is what its users expect. It is what users like Matthew Vernon want: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#20 What you are suggesting above is that the Debian menu will simply be abolished. This seems correct. No-one will be allowed[1] to provide a comprehensive menu in Debian. This doesn't. The trad menu system and the desktop menu system are both, in essence, just a bunch of metadata. What's represented in that metadata is how do you start this particular bit of software. To that extent, they are the same. The actual *contents* of the trad menu system and the desktop menu system is vastly different. I suspect that the opposition to losing the trad menu system is not so much about the metadata *format* as it is about the *contents* of those menu systems; about the actual menus that result from interpreting the metadata. But I don't see why that would need to be a problem, or indeed be part of this question. There is no reason why we wouldn't, theoretically, be able to build a menu system that had a semantically similar (although perhaps differing in minor details, such as categories etc) contents as does the trad menu system, but using desktop metadata rather than trad metadata. There is no reason why moving to desktop files as supported menu system must imply losing most or all of the contents that the trad menu currently contains. It could, yes, and maybe it would make sense if some of the more... unusual menu entries (such as those for bash or python) were removed from the menu system. However, that is a wholly different question as to the question of which metadata format we decide to go with, long-term. I submit that the TC, for the purpose of answering this question before it, should at first simply decide on a preferred metadata format. The contents of the resulting menus is something they can then decide on as a separate question (or ignore altogether if they decide it is not appropriate for them to make that decision). I will add that the debian menu is an all-or-nothing approach; TTBOMK it is not possible to create an entry in the Debian menu saying something along the lines of this should not be shown by default or this should not be shown by default in environment X. This might be one reason for the choice of some of our DE maintainers to decide not to show the Debian menu anymore. The same is not true for the desktop metadata format. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Keith Packard writes (Bug#741573: Two menu systems): Yeah, there are a lot of inappropriate entries in my /usr/share/menu directory. Can we fix policy to weed these out? The current wording in §9.6: All packages that provide applications that need not be passed any special command line arguments for normal operations should register a menu entry for those applications. seems problematic to me -- it seems to require menu entries for things as diverse as a web browser and a python interpreter. Coming up with wording that encourages only programs which are conventionally used in interactive mode to be included seems like a good fix here. I think this is the heart of the disagreement. The traditional Debian menu system (mostly done by Bill Alombert) has been providing menu entries for bc and dc and everything for years. That is what its users expect. It is what users like Matthew Vernon want: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#20 What you are suggesting above is that the Debian menu will simply be abolished. No-one will be allowed[1] to provide a comprehensive menu in Debian. The present dispute has arisen because, although the traditional Debian menu maintainers do almost all of the work of providing all the needed patches to enable packages to provide menu entries, some package maintainers have decided to block that work by refusing the patches. It does appear that the users and developers of the .desktop-style menus are in a majority. But there are users who want to use the comprehensive traditional Debian menu, and there are developers who want to continue to do the work to keep it up to date. We don't allow maintainers to block translation updates; we don't expect them to block the provision of manpages (even though some people think manpages are obsoluete); we shouldn't allow them to block the trad menu system updates. And we should certainly not tolerate this deliberate dismantling of a working and maintained system, simply because some of its opponents consider it obsolete. A facility should be declared obsolete when it no longer has maintainers who can (or want to) keep it working. At the very least if we declare the trad menu system protocol obsolete, there should be a clear plan for how to provide _the same menus_ via .desktop files. That *doesn't* mean `the menus that the .desktop file proponents think everyone should want'. It means `the menus that the trad menu system users and developers currently have, and actually want to keep'. Ian. [1] I say `no-one will be allowed' because in the absence of support from policy, attempts by menu developers to provide entries for non-desktop programs, will be thwarted by the individual package maintainers. If I may extend the transation analogy: if we were to remove the material about translations from Debian's normative documents, and declare translations obsolete (in favour of English, I suppose), no-one would be allowed to make a comperehensive translation of Debian. That is because there would be some maintainers who would simply refuse to take translations on the grounds that translations are obsolete and it's not worth the small effort to integrate translation patches. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Dear TC, I would like to react to Ian's message, that uses words like deliberate dismantling that can be interpreted as if the misbehaviour is on my side, and will add a remark on the fact that Policy maintainers have no veto in contrary to what seemed implied in November's TC meeting on IRC. First, there is no dismantling of the Debian menu in the Policy. Ian calls this menu comprehensive, but the reality is that its coverage is patchy, in sharp contrast with the must directive in the Policy. The patch applied changed this to a should, which is a strong statement that is ground for overriding maintainers refusing patches with no reason. This adjustement of the Policy to the current practice was the core answer to the original requirement in #707851. On top of this change I wanted to take the opportunity to brush up the Policy by describing how to use FreeDesktop menu entries in Debian. Very unfortunately, this gave the impression that one menu system replaces the other, but in practice it is two parallel changes. This is why I am asking the TC to refrain from refactoring that part of our work: it has full consensus, and to be honest, I would feel it a big slap in my face (in the sense that it would call for me reconsider if my contribution is really welcome) if the TC would bypass the Policy change process to modify the changes related to the FreeDesktop menu. Ian's message goes in length on obstructive behaviours. I disagree with such behaviours and I think that the TC should override maintainers who deliberately block the work of others for tactical reasons. The obstruction discussed here is the one of a Policy editor who ignored the Policy changes process and engaged in an blocking strategy by withdrawing the discussion and then reverting the consensus-driven changes unilaterally. In the Policy changes process there is no vote and there is no veto. Bill had ample time to make his points when the discussion was opened. See through the BTS entry: I took all the time needed - more than eight months ! - to address people's reactions and seek consensus. The consensus was assessed by a Policy editor, which is the final point of the process. Bill's behaviour turns the whole discussion into a waste of time, and leaves the Policy in a state that does not reflect the reality. Far from increasing the coverage of the Debian menu systems, Bills commit reversal undermines the value of Debian's policy manual and sends the message that the personal opinion of Policy editors has precedence on consensus (and the *work* that it represents to create that consensus). For this reason, sorry to repeat myself, I am asking the TC to please rule on the question that I raised: should Bill's commit reversal be overriden ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Le Mon, Jun 30, 2014 at 10:25:41PM -0700, Keith Packard a écrit : I think this does demonstrate that we could, with little effort, allow applications to ship only .desktop files and have the menu package take those and generate menu files for other systems. Hi Keith, your approach is laudable, but most of what you propose has already been discussed years before, and regardless how little the effort looks like, nobody ever stepped in to implement it. Instead, why not making a decision on whether it was acceptable or not to revert a commit that had been seconded by enough developers and recognised as consensual by a Policy editor ? This is the core of the problem: the Policy changes process works and there is no need for the CTTE to steer Debian's policy on menus, it is just that the result of one year of consensus-building it is blocked by a single person. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Keith Packard kei...@keithp.com writes: Thanks for pointing that out. desktop2menu is a perl script which uses the published perl bindings for .desktop files and has a start at a mapping from .desktop Categories to menu sections. It also doesn't correctly handle generating .xpm files for the icons. I think this does demonstrate that we could, with little effort, allow applications to ship only .desktop files and have the menu package take those and generate menu files for other systems. Isn't this the tool that Sune wrote and mentioned earlier in this bug as being incomplete and primarily useful for generating a template that requires subsequent work? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#45 -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
On Monday 30 June 2014 23:23:53 Russ Allbery wrote: Isn't this the tool that Sune wrote and mentioned earlier in this bug as being incomplete and primarily useful for generating a template that requires subsequent work? Correct. The primary issue is that there isn't a 1:1 mapping between all categories. I don't exactly remember the exact categories, but an example could be that the debian menu format generally have a 'game' category, whereas the desktop file based spec has a hierarchy of game categories, where the top level should be empty. by looking in the desktop2menu script in the giant mapping table for !WARN should show where the mapping can't be done, or there are no good actual match. There is also, iirc, a couple of other oddities here and there that says I wouldn't want to use it in a automatic fashion. I do think that arch's XdgMenu package is a much better approach for getting a xdg-based menu into various window managers, but it should really be maintained by someone in debian who has a use for it. (that will likely exclude Plasma users like me and Gnome users like Joss) /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Russ Allbery r...@debian.org writes: Isn't this the tool that Sune wrote and mentioned earlier in this bug as being incomplete and primarily useful for generating a template that requires subsequent work? The only two gaps I saw were in the assignment of sections from the Categories in the .desktop file, and in the construction of a suitable .xpm icon. The former could easily be solved by extending the .desktop format to include additional information to compute the section value accurately. -- keith.pack...@intel.com pgpbQ9J1Ltl1j.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
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 pgpFBke5jjcNX.pgp Description: PGP signature
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 pgpKTOr3jEr31.pgp Description: PGP signature
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Cameron Norman camerontnor...@gmail.com writes: I believe the major aspect of .desktop files that makes them harder is the icon handling. Perhaps debian policy should instruct that a certain icon size must always be available in a particular format (e.g. 32x32 png) so that WMs do not have to handle so many corner cases in that area. A window manager will need to handle resizing of icons in any case, and it's pretty darn hard to pin down which sizes to require when so many screen sizes and resolutions are in common use these days. Ideally, the icon artwork is presumably coming from upstream and not constructed for packaging purposes; that will naturally limit the icons to what is provided, making mandating specific sizes somewhat impractical. Of course, I would encourage application developers to provide .svg icons instead of fixed sizes. That gives the window manager the ability to present something good looking at any size. -- keith.pack...@intel.com pgpErTMf4QhWh.pgp Description: PGP signature
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 pgpvpQraRYveI.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 pgpNnT4au_b4H.pgp Description: PGP signature
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.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 pgpARjJ53kHCi.pgp Description: PGP signature
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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
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
Ian Jackson writes (Re: Bug#741573: Two menu systems): But I'd like to make some specific comments too. (I'm reading 24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a copy.) ... Oh, and: Fourthly: It makes no provision for the translation into the new regime of the carefully curated organisational structure of the existing Debian menus. Without such a translation it amounts to throwing away a lot of work. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
(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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think that all of these features (desktop files, trad menu entries, manpages and doc-base bugs) should have the same status. I would describe that status like this: * A maintainer should not be criticised for uploading a package without the feature. * Contributions to provide the feature are encouraged. * A maintainer should accept a patch which provides the feature (unless there is something specifically wrong with the patch). * In particular a maintainer should not decline such a patch on the grounds that they think the feature is not important or does not justify the effort of merging (and if necessary carring) the patch. * lintian ought to report the lack of the feature as a warning (supposed lintian can determine reasonably accurately whether the feature is applicable to the package). I'm not sure that bug severity is a particularly good way of encoding this kind of information. Maintainers have different approaches to bug severity and in general what a particular severity means (at normal or below at least) is generally up to the maintainer. Having said that I don't think wishlist is quite right for this. I think minor is closer. I think that for a wishlist bug a maintainer might reasonably decline a contributed patch on even fairly minimal grounds. For the Lintian tag severity, minor/certain translates into a warning. Anything less than that translates to an info (I) tag. # Map severity/certainty levels to tag codes. our %CODES = ( pedantic = { 'wild-guess' = 'P', possible = 'P', certain = 'P' }, wishlist = { 'wild-guess' = 'I', possible = 'I', certain = 'I' }, minor = { 'wild-guess' = 'I', possible = 'I', certain = 'W' }, normal= { 'wild-guess' = 'I', possible = 'W', certain = 'W' }, important = { 'wild-guess' = 'W', possible = 'E', certain = 'E' }, serious = { 'wild-guess' = 'E', possible = 'E', certain = 'E' }, ); So if you feel like these are minor bugs (and that sounds about right to me), they would naturally end up as warning Lintian tags provided that Lintian can reliably detect the absence. But that's a big caveat; see below. Note that your feel for the severities isn't currently what Lintian implements. Missing man pages are currently marked as a normal bug. If they were marked as minor, they would drop to an I tag, since Lintian can't reliably determine whether a man page is present (due to man pages provided by separate arch: all packages and a dependency). Missing doc-base registration is currently wishlist/possible (same problem on certainty). I don't believe there is any Lintian diagnosis for missing menu integration, nor (intentionally) for a missing desktop file since it's not clear whether a given package should have a desktop file, given the desired integration criteria. It would be tricky to diagnose this in Lintian, since there are a lot of binaries in /bin and /usr/bin that should not have any sort of menu integration. Consider pkg-config, for example. So... I'm a little dubious of your desire for all of this to be Lintian warnings, since I don't think that matches Lintian's current criteria for warnings, but I do think that the severity of the missing man page Lintian warning may be a little overstated at the moment. I have no idea how one would go about writing an effective Lintian check for missing menu integration without forcing a ridiculous and undesireable number of overrides. In general, I like your breakdown of expectations about maintainer behavior. This feels like some sort of desired feature level of Policy description, which would fall between should and may. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Stuart Prescott writes (Bug#741573: Two menu systems): On Fri, 11 Apr 2014 21:04:12 Ian Jackson wrote: I don't imagine you're proposing changing the wording of the sections of policy on doc-base entries, manpages, etc. to may. Indeed I am not proposing that. I believe those are things that the maintainer should provide as part of the package. Then in disagree. But I think I disagree with you about manpages more than I do about menu entries. In practice the archive is absolutely full of programs without manpages and it doesn't make sense to insist that every maintainer preparing a package should also write a manpage. Writing manpages is a lot of work, and is also a distinct skill that many packages don't necessarily have. (The mechanisms for trying to generate manpages automatically are fragile and unpleasant and generate rather poor output, so that's not really an answer.) The upshot is that we don't currently insist that maintainers provide manpages. I have never been criticised by anyone for uploading or sponsoring anything with missing manpages. I don't think anyone else should be criticised for that. (Of course sometimes people have filed bugs providing manpages, which is very welcome.) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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). There are doubtless many things that could be done to make it easier for maintainers who largely prefer desktop files to support the traditional menu as well. Part of the reason why this bug was raised in Policy in the first place is that none of them have actually happened, and that didn't seem that likely to change. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Russ Allbery writes (Bug#741573: Two menu systems): That's not should in the Policy sense. Should in the Policy sense does, in fact, mean that you have to do work to support it, although the level of pressure is only mild rather than at the level of rejecting the package entirely. As I say, policy doesn't say who should do the work. It just says what the package should look like. Whether a package that doesn't conform to all the shoulds in policy ought to be included in the archive is surely a decision for the packager. If you think this needs clarifying somewhere, I don't think anyone will object. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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 pgpGbSJKigOJy.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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
On Wed, Apr 09, 2014 at 01:27:46PM -0400, Sam Hartman wrote: Thanks for bringing this issue back to the question that was brought to the TC. The discussion so far on this bug has focused on discussing what the right menu policy is for Debian. That, however was not the question that was brought to the TC. It is my understanding that this is exactly the question that has been referred to the TC, because the default policy process only works when there is a consensus - and there is not a consensus here. So it necessarily falls to the TC to decide what the policy should be, in the absence of this consensus; and while the TC should not do detailed design work, it would also be counterproductive to try to limit ourselves to giving all answers in the form of a boolean. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
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. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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
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
Le mardi, 8 avril 2014, 18.30:26 Ian Jackson a écrit : Technology: The two systems have different file formats. While the semantics of the information presented overlap, there are substantial differences in the capabilities of the two systems. The 'trad' menu file or the 'desktop' xdg file are only the starting point of their technical differences; one other technical difference that matters is the support for icon formats. From the 'desktop' icon theme spec: The supported image file formats are PNG, XPM and SVG. PNG is the recommended bitmap format, and SVG is for vectorized icons. XPM is supported due to backwards compability reasons, and it is not recommended that new themes use XPM files. Support for SVGs is optional. In practice, we have icons up to 1024^2 in PNG and only vlc and libreoffice (on my system) ship .xpm icons in the xdg repositories. From the 'trad' Debian Menu System: * The icons should be in xpm format. * The icons may not be larger than 32x32 pixels, although smaller sizes are ok. (…) You can provide both 16x16 and 32x32 pixels icons using the variables icon16x16 and icon32x32 so that the user can configure menu to use one or the other. This doesn't say what non-xpm icon formats are supported and in practice, the icon path also has to be specified completely; one can't provide more than two (fixed) icon resolutions either. Enforcing the use of the antique XPM format in a limited resolutions set is one of the pains of the 'trad' menu system IMHO. In practice, in order to add an xpm icon to one of my packages [0] which already shipped a .desktop file, an SVG icon and built various sizes' pngs at build-time using rsvg-convert [1], I had to add an imagemagick build-dependency and convert it out of the 32^2 png icon as I didn't find a software to convert the svg directly to xpm. Frankly, I don't mind shipping a .menu file in debian/ as that's picked by dh_installmenu, but it would be vastly better if the 'trad' menu could at least adopt the freedesktop icon theme specification. The fact that this is a Debian specificity that saw no upload in two years, I'd be surprised to see much further developement happen though. Cheers, OdyX [0] src:colobot if that matters [1] To be fair, I proposed that code to upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
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
Le mercredi, 9 avril 2014, 15.00:44 Ian Jackson a écrit : Right. I understand that some people don't think the comprehensive menu is useful. However, there are a lot of things in Debian that some people think aren't useful. The usual principle is that if someone thinks something useful and wants to do the work to provide it, they should be able to do so. I think this is allowed by the patch pointed by Charles, which adds the following paragraph to the policy: Packages can, to be compatible with Debian additions to some window managers that do not support the FreeDesktop standard, also provide a 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. As I read it, the complete patch is essentially the addition of a 'desktop' menu 'should' and a s/should/can/g for the 'trad' menu. That patch got its three seconds within the usual Policy process but got (fully) reverted by Bill. Are you suggesting the 'trad' menu should stay at 'should'? Do you agree with the promotion of the 'desktop' menu to a 'should'? (snip a lot of vocabulary nitpicking) Let's rephrase succintly then: xpm is an old format; there is a trend showing that more and more packages ship .desktop files [0] along with svg and/or png icons; it would therefore ease maintainers' adoption of 'trad' menu entries if the 'trad' menu would just support these new icon formats in addition or in replacement of xpm. That's all I wanted to say. There are significant advantages to use of a longstanding file format. These advantages are more important in the widely-consumed trad menu than they would be in the less-widely-consumed but more sophisticated desktop menu. Your assertions about how widely the two menu systems are consumed seem quite bold to me and are at least not backed by Cyril numbers in 741573#35 [0]. Cheers, OdyX [0] 20140325185237.ge15...@mraw.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Didier == Didier 'OdyX' Raboud o...@debian.org writes: Didier I think this is allowed by the patch pointed by Charles, Didier which adds the following paragraph to the policy: Packages can, to be compatible with Debian additions to some window managers that do not support the FreeDesktop standard, also provide a 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. Hi. Thanks for bringing this issue back to the question that was brought to the TC. The discussion so far on this bug has focused on discussing what the right menu policy is for Debian. That, however was not the question that was brought to the TC. As I understand it, the claim was made that a consensus was reached through the normal process and that one of the maintainers reverted changes consistent with that consensus because he questioned whether the consensus call was correct. I appreciate that deciding menu policy is within the scope of the TC, and if the TC finds that there is no consensus, it seems entirely reasonable for the TC to choose to create such a policy. However, I'm disappointed when I see TC members diving into the technical details in this instance. I hope that the TC would respect the broader decision making within the project, would support the idea that if a broader decision can be reached, that iit is valuable to support that. If there is a broader consensus based on the discussion within the policy process I'd hope that TC members would be very reluctant to re-open that even if the decision reached is not the one they are most in favor of. There's a significant cost to being involved in a consensus process that doesn't reach a conclusion. I'd hope that the TC members would choose to respect the time and energy of all those who participated rather than taking everything on themselves. So, I'd like to request the TC to first consider whether a consensus was reached in the process and if so whether there's a compelling reason not to respect that consensus. If no consensus was reached or the TC finds it has a compelling interest not to respect that consensus, then focusing on the technical details of the policy seems reasonable. In my opinion, not respecting the project as a whole enough to make a determination about consensus does significant harm. Respectfully, Sam Hartman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Sam Hartman writes (Bug#741573: Two menu systems): So, I'd like to request the TC to first consider whether a consensus was reached in the process and if so whether there's a compelling reason not to respect that consensus. If no consensus was reached or the TC finds it has a compelling interest not to respect that consensus, then focusing on the technical details of the policy seems reasonable. In my opinion, not respecting the project as a whole enough to make a determination about consensus does significant harm. This is hardly the first time that a matter has come to the TC after a dispute has escalated to acts (on one or both sides) whose legitimacy is disputed. I doubt it will be the last. Our approach has always been to look at the underlying dispute and try to resolve it. So, no. The TC will not make decisions about the content of policy on the basis of an adjudications about the policy process. We will rule on the underlying question(s), on the merits. (In my view, the menu question should have been referred to the TC much sooner.) The legitimacy of the actions of the policy maintainers is a matter for the policy team as a whole, and in extremis for the DPL (given that the policy team are DPL delegates). However I would strongly encourage everyone not to dwell on the alleged wrongs of the disputants. Such discussions are unpleasant and almost always unproductive. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Le Wed, Apr 09, 2014 at 11:34:51PM +0100, Ian Jackson a écrit : It is the demotion of the traditional menu from should to can which is controversial. For the reasons I have already explained, I do not agree with that. Hi Ian, yes, it is that part that is controversial, and I would appreciate if the TC would focus on it, since this was the original topic of #707851, entitled “soften the wording recommending menu files”. The underlying question is: who should spend the time writing these files and keeping them up to date ? In the case of missing manual pages, the policy (§ 12.1) does not require the package maintainer to write one. As a general principle, I think that this is the right way. Pacakge maintainers are volunteers, and we should be careful to avoid loading them with extra work. Therefore, I think that the “should” of §9.6, paragraph 2 should be relaxed. Needless to say, patches carrying Debian menu entries should be accepted. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
I have a very different take on this to Russ. We currently have two menu systems. I'm going to call them the trad and desktop menus. They have the following very important differences (some of these are matters of opinion, but I will take what appear to me to be the opinions of their respective maintainers): Scope: The trad menu is supposed to contain pretty much everything that can be executed, including command-line programs (to be run via a terminal). For example, bc has a trad menu entry. Conversely, the desktop menu is supposed to contain only a subset of programs that are considered useful for users to find and invoke via a menu. Organisation/categorisation: Both the trad and desktop menus have had effort put in by their respective maintainers into organising the menus into subheadings etc. However, these categorisations are different. Consumers: The trad menu is already consumable by a very wide range of window managers etc.; the desktop menu is consumed primarily by desktop environments. Technology: The two systems have different file formats. While the semantics of the information presented overlap, there are substantial differences in the capabilities of the two systems. The trad menu makes lower demands on menu entry consumers, and conversely imposes more restrictions on menu entry providers. The desktop menu gives more flexibility for menu entry providers, and consequently is harder to support as a menu consumer. Both menu systems have sufficient supporters and users that they are independently viable projects. Some people will say that the trad menu is dead and no-one uses it, but that's clearly not true. Consider the package http://qa.debian.org/popcon.php?package=menu-xdg which provides a view of the trad menu in desktop system which supports the desktop (XDG) menus. It therefore seems to me that the correct approach is to continue to support and develop both these systems. Given the historical conflict between the maintainers of the two systems, we need to lay down clear boundaries. In the spirit of do-ocracy, decisions about each menu system should be made by its respective sets of maintainers. So each menu system's maintainers should: * Determine the technical and social policy for their own menu system (subject to the usual review); * Decide for their own system whether a particular package should have an entry in that menu. (Initially, such decisions would be made by the package maintainer of course, guided by policy); * Decide how that menu entries should be categorised; * Decide if and when to make changes to their file format and infrastructure, including developing appropriate transition plans etc. I.e., each menu system's maintainers and proponents should be enabled to do the work they want to do, to make the menu system that they prefer be as good as it can be. No-one should block their work or nonconsensually deprecate it. My conclusion is: * Debian policy should contain two sections on menus. * Section on the trad menu should say what it currently says. In particular, it should continue to say that pretty much all relevant packages should provide trad menu entries. Failure to provide a trad menu entry (when the trad menu maintainers would like such a menu entry to exist) is a bug. * Section on the desktop menu should say whatever the desktop people think is appropriate, including descriptions of file formats, when and how to categorise entries, etc. As above, failure to provide a desktop menu entry when the program is covered by the guidelines would be a bug. As a consequence, many maintainers will need to provide both files in their output binary packages. This is by no means an unreasonable burden on individual package maintainers. No-one is suggesting that failing to provide a menu entry would be an RC bug. We should treat this the same way we treat lack of a manpage: there are plenty of packages in Debian with no manpages. But we expect that if someone who is keen on manpages writes a manpage, the package maintainer will take the patch. (And the risk with manpages, that they become out of date, doesn't really apply for menu entries.) A maintainer of a package which wants to be in both menus might choose to put two separate menu entry source files in their source package. I think this is probably the best approach: the amount of metadata duplication involved is minimal, and having two source files avoids any possibility of irreconcilable conflict between the opinions of the two menu systems. But if a maintainer wants (for example) to generate a trad menu file from an desktop file, then that's fine. BUT this is ONLY PROVIDED that the generated trad menu file is properly confirming to the trad menu specification and has the descriptive text, categorisation, etc., preferred by the trad menu maintainers. Thanks, Ian. -- To UNSUBSCRIBE, email to
Bug#741573: Two menu systems
Hi I think there is a couple of facts that aren't fully accurate. I'll try to mention them here. I'll try to keep opinions out of this mail. On Tuesday 08 April 2014 18:30:26 Ian Jackson wrote: Consumers: The trad menu is already consumable by a very wide range of window managers etc.; the desktop menu is consumed primarily by desktop environments. Note that a very wide range of window managers neither supports the trad. menu nor the desktop menu, but has a series of scripts to modify one or the other into their native format. In Debian, most of these window managers only has the scripts for the trad. menu, while the rest of the internet have the scripts that uses the desktop menu. Both menu systems have sufficient supporters and users that they are independently viable projects. Some people will say that the trad menu is dead and no-one uses it, but that's clearly not true. Consider the package http://qa.debian.org/popcon.php?package=menu-xdg which provides a view of the trad menu in desktop system which supports the desktop (XDG) menus. Note that the KDE Desktop task until earlier this year did install menu-xdg, and still does it, and the Gnome and XFCE desktops tasks also installed it at one point, so these numbers aren't fully usable. But if a maintainer wants (for example) to generate a trad menu file from an desktop file, then that's fine. BUT this is ONLY PROVIDED that the generated trad menu file is properly confirming to the trad menu specification and has the descriptive text, categorisation, etc., preferred by the trad menu maintainers. As the author of desktop2menu, I can tell that in some cases it is possible to generate it, but in the general case it is not possible to use autogeneration. It is - like the help2man script - good to create a template. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
On Tue, Apr 08, 2014 at 10:23:50PM +0200, Sune Vuorela wrote: Note that a very wide range of window managers neither supports the trad. menu nor the desktop menu, but has a series of scripts to modify one or the other into their native format. In Debian, most of these window managers only has the scripts for the trad. menu, while the rest of the internet have the scripts that uses the desktop menu. That's right. Like I mentioned earlier, with my Fluxbox maintainer hat on, getting rid of traditional menu system for desktop sounds great; might even lead to fixing this upstream, rather then doing it in the Debian packaging. Everyone else seems to be using xdg-menu these days anyway; taking a guess (I've not checked this out), GNOME, KDE and Xfce likely all use XDG menus, so I think Fluxbox is the largest consumer. (Sune, Xfce people, correct me if I'm wrong :) ) I'm happy to change it to use XDG menus, or accept patches doing so. Note that the KDE Desktop task until earlier this year did install menu-xdg, and still does it, and the Gnome and XFCE desktops tasks also installed it at one point, so these numbers aren't fully usable. But if a maintainer wants (for example) to generate a trad menu file from an desktop file, then that's fine. BUT this is ONLY PROVIDED that the generated trad menu file is properly confirming to the trad menu specification and has the descriptive text, categorisation, etc., preferred by the trad menu maintainers. As the author of desktop2menu, I can tell that in some cases it is possible to generate it, but in the general case it is not possible to use autogeneration. It is - like the help2man script - good to create a template. /Sune Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature