Bug#746715: Init system fallout draft resolution
Ian Jackson ijack...@chiark.greenend.org.uk writes: Here is the resolution text that I think we agreed at the last meeting. I formally propose this text: The issue of init system support recently came to the Technical Committee's attention again.[1] For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. [1] See #746715 for background. As discussed I deleted the contextual and motivational paragraphas and replaced them with the vague intro sentence from IRC and put the bug reference in a footnote. Hopefully this will get consensus. I intend to call for a vote no earlier than after the end of the relevant item in tomorrow's meeting. I'm ok with this. Thanks, Ian. Bdale pgpl4Gml18Zzc.pgp Description: PGP signature
Bug#636783: TC chair appointment
I mentioned this on IRC but forgot to get it into the agenda: The TC chair arrangements have what is arguably a bug, which is that the TC cannot change a sitting chair other than by the chair resigning or leaving the committee. I think the TC chair should be reappointed regularly (annually?), and that a new chair election should be held when the TC composition changes. If we are having a formal TC member retirement scheme, and TC chair election when a new member is appointed, then perhaps making explicit provision for time-based chair retirement is unnecessary. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21420.15439.20061.525...@chiark.greenend.org.uk
Bug#746715: Init system fallout draft resolution
On 2014-06-26 16:00, Bdale Garbee wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Here is the resolution text that I think we agreed at the last meeting. I formally propose this text: The issue of init system support recently came to the Technical Committee's attention again.[1] For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. [1] See #746715 for background. As discussed I deleted the contextual and motivational paragraphas and replaced them with the vague intro sentence from IRC and put the bug reference in a footnote. Hopefully this will get consensus. I intend to call for a vote no earlier than after the end of the relevant item in tomorrow's meeting. I'm ok with this. Thanks, Ian. Bdale I thought the concensus had been that no statement was requried --- this is just BAU under normal Debian expectations... -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0fc93da28574d8a68cfe7eccdfab8...@mjr.org
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
On Thu, Jun 26, 2014 at 05:50:38PM +0100, Ian Jackson wrote: I see Keith has committed a draft to git. As discussed, I disagree with this approach. This amounts to nonconsensually abolishing someone's work when it is still being maintained, and the global cost is minimal. My feelings on this draft are mixed. On the one hand, I happen to agree with the position that the categorisation system in .desktop files (and X-Show-In etc.) should be able to cover the bulk of the practical requirements of the trad menu system: * There's no reason that has a .desktop file should imply shows up in modern desktop environments, and so I think that the question of coverage is to some extent a red herring; the systems have different coverage because they've always had different coverage, not because the .desktop format is inherently unable to meet the needs of trad menu consumers. * We might have to look into the presentation of menu item names, although Name / GenericName offers some support for the different names that people are likely to want, and if all else fails the .desktop file format does have extension mechanisms. I would be very happy to see additional .desktop files being added to packages with suitable categorisation such that they don't need to interfere with how the maintainers of modern DEs want to present their desktops, so that menu-xdg (or similar) can supplant the current menu system with negligible loss of functionality for users of trad menus. I think this would make a great project for people interested in unifying the two worlds a bit more, which doesn't even have to step on anyone's toes. Perhaps for instance it would be a good project for Debian's Google Summer of Code efforts. On the other hand, Keith's draft seems highly aspirational to me. While it seems to me to be broadly the right kind of long-term technical direction, there is an awful lot of work in there for people who want something like trad menus which is being glossed over. So, I prefer Ian's position in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the purposes of how the policy text should remain for the time being, and in terms of the philosophy of not ripping out work from under people's feet. I disagree with its argument that it follows directly from the two sets of competing requirements that we must have these two file formats. I prefer Keith's position as a long-term direction, but agree with Ian that it is lacking an awful lot of transitional thought, and feel that it has a lot of things-should-be-done without it being clear who will do them. Thirdly, IMO the resolution needs to acknowledge (in the whereas section) that consuming a trad Debian menu entry is simpler and easier than consuming a .desktop file. I think this is really overstated. .desktop files are in a long-standing and popular basic file format for which plenty of parsing libraries in various languages exist, so you can get to the point of having a parsed data structure trivially. In contrast the menu entry format is a bespoke thing. While the .desktop file format has more bells and whistles, many of them can be ignored if you don't support whatever it is. I don't think it's worth emphasising ease of consumption either way. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626173154.ga1...@riva.ucam.org
Bug#741573: Two menu systems
(Sorry I missed the meeting today. I'm away on vacation and my schedule ended up not aligning properly.) Colin Watson cjwat...@debian.org writes: I think this is really overstated. .desktop files are in a long-standing and popular basic file format for which plenty of parsing libraries in various languages exist, so you can get to the point of having a parsed data structure trivially. In contrast the menu entry format is a bespoke thing. While the .desktop file format has more bells and whistles, many of them can be ignored if you don't support whatever it is. I don't think it's worth emphasising ease of consumption either way. The counterpoint here, which I had missed earlier in this discussion, is the file format for the menus themselves, not the *.desktop files. I agree with you about the *.desktop file format, but the specification for the menus is much more complicated. See: http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html I'm not positive that the syntax of /etc/menu-methods is any less complex, but it's at least arguable, and it's certainly way different and already designed for generating menus for other applications that don't inherently support the XDG menu system. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhsjczm1@windlord.stanford.edu
Bug#717076: libjpeg draft resolution
Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21420.27583.955977.281...@chiark.greenend.org.uk
Bug#746715: Init system fallout draft resolution
As discussed at the meeting, I hereby call for votes on this resolution (text below). There are two options Y Issue statement about (multiple) init system support FD Thanks, Ian. -- resolution text begins The issue of init system support recently came to the Technical Committee's attention again.[1] For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. [1] See #746715 for background. -- resolution text ends -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21420.27741.528211.660...@chiark.greenend.org.uk
Bug#717076: libjpeg draft resolution
Ian Jackson writes (Bug#717076: libjpeg draft resolution): Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A, B, FD Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21420.27920.104110.595...@chiark.greenend.org.uk
Bug#746715: Init system fallout draft resolution
Ian Jackson writes (Re: Bug#746715: Init system fallout draft resolution): As discussed at the meeting, I hereby call for votes on this resolution (text below). There are two options Y Issue statement about (multiple) init system support FD I vote Y, FD Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21420.27933.924320.19...@chiark.greenend.org.uk
Bug#717076: libjpeg draft resolution
Ian Jackson ijack...@chiark.greenend.org.uk writes: As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A, B, FD. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ pgpp3UE_HMxGN.pgp Description: PGP signature
Re: Bug#717076: libjpeg draft resolution
On Thu, 26 Jun 2014, Ian Jackson wrote: Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD I vote A B FD. -- Don Armstrong http://www.donarmstrong.com I would like to be the air that inhabits you for a moment only. I would like to be that unnoticed that necessary. -- Margaret Atwood Poetry in Motion p140 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626201702.ga30...@rzlab.ucr.edu
Re: Bug#746715: Init system fallout draft resolution
On Thu, 26 Jun 2014, Ian Jackson wrote: As discussed at the meeting, I hereby call for votes on this resolution (text below). There are two options Y Issue statement about (multiple) init system support FD I vote Y FD. -- Don Armstrong http://www.donarmstrong.com No amount of force can control a free man, a man whose mind is free [...] You can't conquer a free man; the most you can do is kill him. -- Robert Heinlein _Revolt in 2010_ p54 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626201829.gb30...@rzlab.ucr.edu
Re: Bug#746715: Init system fallout draft resolution
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140626 20:57]: As discussed at the meeting, I hereby call for votes on this resolution (text below). There are two options Y Issue statement about (multiple) init system support FD Voting Y, FD. Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626223731.ge20...@mails.so.argh.org
Re: Bug#717076: libjpeg draft resolution
* Ian Jackson (ijack...@chiark.greenend.org.uk) [140626 20:54]: Ian Jackson writes (Re: Bug#717076: libjpeg draft resolution): I hereby propose the resolution below. I intend to call for a vote no earlier than after the conclusion of the relevant agenda item in tomorrow's IRC meeting. As agreed on IRC, I hereby call for votes on the rsolution below. There options are: A libjpeg-turbo to become default libjpeg implementaton (1:1) B libjpeg8/9 to remain default libjpeg implementaton (1:1) FD Voting A, B, FD. Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626223752.gf20...@mails.so.argh.org
Bug#746715: Init system fallout draft resolution
On Thu, Jun 26, 2014 at 07:54:21PM +0100, Ian Jackson wrote: There are two options Y Issue statement about (multiple) init system support FD I vote Y FD. -- Colin Watson [cjwat...@debian.org] signature.asc Description: Digital signature
Bug#746715: Init system fallout draft resolution
On Thu, Jun 26, 2014 at 07:54:21PM +0100, Ian Jackson wrote: As discussed at the meeting, I hereby call for votes on this resolution (text below). There are two options Y Issue statement about (multiple) init system support FD Thanks, Ian. -- resolution text begins The issue of init system support recently came to the Technical Committee's attention again.[1] For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. [1] See #746715 for background. -- resolution text ends I vote Y, FD. -- 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#746715: Init system fallout draft resolution
Ian Jackson ijack...@chiark.greenend.org.uk writes: As discussed at the meeting, I hereby call for votes on this resolution (text below). There are two options Y Issue statement about (multiple) init system support FD Thanks, Ian. -- resolution text begins The issue of init system support recently came to the Technical Committee's attention again.[1] For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. [1] See #746715 for background. -- resolution text ends I vote Y, FD. Bdale pgpb1yF1oR46p.pgp Description: PGP signature
