Bug#727708: init system discussion status

Steve Langasek vor...@debian.org writes: I would prefer to see more neutral wording, something to the effect of: I didn't mean that the TC decision should mention the CLA. I don't think that's an appropriate place for this kind of statement. -- keith.pack...@intel.com pgpUSSrYvh1Wi.pgp

Re: call for votes on default Linux init system for jessie

Bdale Garbee bd...@gag.com writes: Ballot: The default init system for Linux architectures in jessie should be 1. systemd 2. upstart 3. openrc 4. sysvinit (no change) 5. requires further discussion. I vote 12435 -- keith.pack...@intel.com pgpZ9k37fMjSL.pgp

Re: call for votes on default Linux init system for jessie

Don Armstrong d...@debian.org writes: I think we should break the bigger question into this question plus additional advice for transition after we resolve this issue, but for me to vote things above FD, we should allow for a simple majority GR to vacate this decision. On one hand, we place

Bug#727708: Upstart and the CLA

I've been asked by a couple of people for my thoughts on how the upstart CLA has impacted my position about the default init system for Debian. I think it's pretty clear the upstart CLA was the most damaging at the very start of the project. As Kay and Lennart have intimated elsewhere, the

Bug#727708: call for votes on default Linux init system for jessie

Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it doesn't make sense to allow people to require a non-default init. I think this position is consistent with allowing each maintainer broad autonomy, and not overly burdening them with requirements that may make it difficult or

Bug#727708: call for votes on default Linux init system for jessie

Bdale Garbee bd...@gag.com writes: Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would prefer to vote a ballot that doesn't mention dependencies at all. I agree with this; I don't

Bug#727708: call for votes on default Linux init system for jessie

Ian Jackson ijack...@chiark.greenend.org.uk writes: If we are I to vote now, I would like to see on the ballot at least: DM systemd by default, but also others DO systemd only in jessie+1 UM upstart by default, but also others UO upstart only in jessie+1 RM openrc by

Bug#727708: call for votes on default Linux init system for jessie

Adrian Bunk b...@stusta.de writes: Debian decides that Upstart is the default init system for jessie, but it's default desktop GNOME forces the installation of systemd. There are reasons I've left gnome behind... -- keith.pack...@intel.com pgpud6GoOLbVe.pgp Description: PGP signature

Re: Next CTTE meeting at date -d 'Thu Jan 30 18:00:00 UTC 2014' in #debian-ctte on irc.debian.org

Steve Langasek vor...@debian.org writes: On Tue, Jan 28, 2014 at 04:59:10PM -0800, Don Armstrong wrote: The next CTTE meeting is at date -d 'Thu Jan 30 18:00:00 UTC 2014' in #debian-ctte on irc.debian.org FYI, I'm travelling this week and don't believe I'll make it to this meeting. I don't

Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.

Sergey B Kirpichev skirpic...@gmail.com writes: Are X-people indeed sacrifice portability, or there is something different (e.g. these dependencies are optional)? Speaking as the X server release manager, the systemd patches exist solely to provide for interoperation with systemd or other

Bug#727708: init system resolution - revised proposal

Ian Jackson ijack...@chiark.greenend.org.uk writes: Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good ballot. Steve, Colin, Keith: let us know, and perhaps we can start the vote sooner. I can vote with this ballot. Sorry I had to disappear in the middle of the meeting; that

Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.

Matthias Klumpp matth...@tenstral.net writes: Of course it does not exclude implementing that stuff in a different, non-systemd tool, but to my knowledge nobody has done that yet. Exactly so. I have ideas on how this might work in a simpler and more general fashion, but people rarely listen to

Re: Bug#727708: Call for votes on init system resolution

Colin Watson cjwat...@debian.org writes: I think I signed my votes when I started on the TC, but then noticed that nobody else was doing so and stopped bothering. I can go back to signing them in future, though, since it sounds like it would make some people more comfortable. I just sign

Bug#727708: Call for votes on init system resolution

Russ Allbery r...@debian.org writes: I consider the L option as currently written to be a commitment to a course of action that is technically broken and unsustainable. I also think the effect of L is contrary to its intended goal and will make it less likely, not more likely, that Debian

Re: call for votes on default Linux init system for jessie

Steve Langasek vor...@debian.org writes: I agree with Ian on this. At this point, it should be clear to everyone that, given the stated preferences of each member of the TC, the default init system for jessie will be systemd. Let's finish that vote then and move on. But I do not think this

Re: call for votes on default Linux init system for jessie

Russ Allbery r...@debian.org writes: Well, in defense of the discussion that Steve, Colin, and I have been having, I do think it's worthwhile for the TC to try to hammer out a compromise on that point as well and express it as either technical advice to the project or as technical policy.

Re: Understanding the current state

Russ Allbery r...@debian.org writes: This is still a live discussion as far as I'm concerned. There is some debate whether this is even something that the TC should be deciding right now (Keith, as I recall, expressed that position). Right, given that the discussions on this list have been

Re: Deposing the chairman of the Technical Committee

Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby propose the following TC resolution. The Technical Committee has lost confidence in the Committee's Chairman and requests that the Chairman resign. I vote FD above all other options. -- keith.pack...@intel.com

Bug#727708: Init system Call for Votes, Ian's drafts

Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby call for votes on my own formal proposal. I vote FD above all other options. -- keith.pack...@intel.com pgprr2wx4nVKf.pgp Description: PGP signature

Bug#727708: Init system coupling call for votes

Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby call for votes on the following resolution: The init system decision is limited to selecting a default initsystem for jessie. We expect that Debian will continue to support multiple init systems for the foreseeable

Bug#727708: Init system GR override call for votes

Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby call for votes on the following resolution If the project passes (before the release of jessie) by a General Resolution, a position statement about issues of the day, on the subject of init systems, the views expressed in

Bug#727708: call for votes on default Linux init system for jessie

Steve Langasek vor...@debian.org writes: If the chair ranked them equally in his ballot, why should he express a different preference when it comes to the casting vote? Oh, the obvious answer -- if the chair's preference didn't end up in the tie, he'd have to explicitly vote from the remaining

Bug#727708: init system coupling etc.

Ian Jackson ijack...@chiark.greenend.org.uk writes: [loose coupling] Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Maintainers are encouraged to accept technically sound patches

Bug#727708: init system coupling etc.

Russ Allbery r...@debian.org writes: The following is technical advice offered to the project by the Technical Committee under section 6.1.5 of the constitution. It does not constitute an override of maintainer decisions past or future: Thanks for making this clear -- operating

Bug#727708: init system coupling etc.

Ian Jackson ijack...@chiark.greenend.org.uk writes: I don't think this is likely but I can see why you would want to try that. Thanks. Being new to the TC, I may feel more reluctant to exercise it's process than people more familiar to the role. And it is different from FD in that if enough

Bug#727708: init system coupling etc.

Ian Jackson ijack...@chiark.greenend.org.uk writes: Perhaps you would like to change this to something like: The TC chooses to not pass a resolution at the current time about whether software may require specific init systems. I don't formally propose this because I see no point on

Bug#727708: init system coupling etc.

Ian Jackson ijack...@chiark.greenend.org.uk writes: I've done so, thanks. Looks good. -- keith.pack...@intel.com pgp6pLZwyhYsw.pgp Description: PGP signature

Bug#727708: Call for Votes on init system coupling

Ian Jackson ijack...@chiark.greenend.org.uk writes: I hereby call for votes on my coupling proposal and the amendments that have been put. The options on the ballot are: L Software may not depend on a specific init system N No TC resolution on this question at this time A

Re: Scheduling the Next Debian CTTE Meeting

Don Armstrong d...@debian.org writes: I don't have a problem with this myself; does anyone have a problem with date -d'Thu May 22 17:00:00 UTC 2014'? Either date is fine with me; see y'all then. -- keith.pack...@intel.com pgpZ1Y3eYAo71.pgp Description: PGP signature

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

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

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

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.

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

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

741573: menu system. Added list of alternative solutions

I've been thinking about how to make progress on 741573, the menu system bug, and have decided to try and focus our discussion on constructing a suitable ballot for a vote. I've added a list of potential ballot items to the repository and hope that we can work on eliminating as many as possible,

Bug#762194: On automatic init system switching on upgrade

Svante Signell svante.sign...@gmail.com writes: 4. For the moment, we invite concrete proposals for technical changes which would arrange that 1. new jessie installations using Linux would get systemd but 2. existing installations retain their existing init system so far as possible.

Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering

Anthony Towns a...@erisian.com.au writes: ​The tech ctte could've addressed this issue by providing policy guidance or by just offering advice, and assuming that the systemd maintainers would act on th​e advice or policy in good faith. Choosing to override the systemd maintainers was far from

Re: Call for Votes for new CTTE Chairman

Bdale Garbee bd...@gag.com writes: === BEGIN I know my vote isn't necessary to help determine the outcome of the election, but I felt it would be useful to also record my support for Don in this role. A (B | D) (E | F | G) (C | H) Thanks much to both Bdale (for having served for nearly a

Re: Do we want to submit a sprint request for debconf

Sam Hartman hartm...@debian.org writes: A couple of weeks ago I noticed mail to d-d-a talking about sprints at debconf. I'm wondering whether we want to try and spend a day at debconf or debcamp exploring how we want to work together, how we want to resolve issues, working on internal

Re: Do we want to submit a sprint request for debconf

Didier 'OdyX' Raboud o...@debian.org writes: Ideally, given quorum, we could also take advantage of that time together to push pending issues, and (help) clear our backlog. While I think this could be done within the bounds of the constitution, it would eliminate participation from absent TC

Re: Polling open for next CTTE Meeting (and default in future)

Don Armstrong d...@debian.org writes: This is a non-binding poll for the default meeting times for future CTTE meetings. A: Tuesday 16:00 UTC (April 28th) B: Tuesday 17:00 UTC (April 28th) C: Tuesday 18:00 UTC (April 28th) D: Tuesday 19:00 UTC (April 28th) E: Tuesday 20:00 UTC (April

Re: Chair Re-appointment after new membership procedure

Don Armstrong writes: > When new members are appointed to the CTTE or within three months of a > member resigning from the CTTE, the current chairperson should > announce their intention to vacate the position within two weeks. Seems reasonable to me. -- -keith

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Steve Langasek vor...@debian.org writes: 741573_menu_systems/keithp_draft.txt includes further guidance regarding the technical details of how to map between the menu system and .desktop files. Since this is not on the ballot itself, how do we intend to surface this so that it can be useful

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Charles Plessy ple...@debian.org writes: Thanks. I would appreciate if it would be acknowledged, I am a bit academic by training... The proposed ballot tries to clarify the difference between D and AB by noting: 6. The policy change by Charles Plessy in ba679bff76[1] would comply

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Sam Hartman writes: > I ask you to retain the following two paragraphs that explain why we > prefer option D should we adopt this: >The Technical Committee has reviewed the underlying technical >issues around this question and has resolved that Debian will be >

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Sam Hartman writes: > I think a bit. > My big question is whether you think we'd still be able to call for a > vote tomorrow if we make this change. I think the change has real benefit beyond simple clarification by immediately adopting Charles' changes to policy without

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Sam Hartman writes: > OK. > I'd really appreciate hearing from anyone now who needs more time before > a CFV. I'd also love to hear back from Charles about the updated D proposal, and whether that helps him understand what it means. -- -keith signature.asc Description:

Bug#741573: CFV: Debian Menu Systems

I vote: D>B>A>Z>C -- -keith signature.asc Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Ian Jackson ijack...@chiark.greenend.org.uk writes: * Overall, this would make it possible, therefore, to maintain the menu information primarily in the more sophisticated .desktop format, so that source packages with .desktop files would not need to contain trad menu files too.

Re: Scheduling the next Debian CTTE Meeting

Don Armstrong writes: > The 23rd->25th; sorry. I must have been distracted when I was finishing > that up. No worries. I voted assuming that was the case. -- -keith signature.asc Description: PGP signature

Re: Debconf

Sam Hartman writes: > It was asked who plans to go to debconf in the meeting today. > It's my plan to go. I'm planning on going and have travel approval from $dayjob for the event. Looking forward to meeting you there in a few months. -- -keith signature.asc

Bug#830978: Browserified javascript and DFSG 2

"Paul R. Tagliamonte" writes: > Traditionally, ftpteam has had to take this role, since it is the body > that decides if an upload is fit for main. Yup. > I haven't talked in-depth with the rest of the ftpteam, but I assume > they agree. CC'ing in case there's an objection.

Bug#822803: Call for votes for new TC member

Didier 'OdyX' Raboud writes: > [ Unknown signature status ] > Dear TC members, > > I hereby call for votes on the following ballot to fill the vacancy in > the TC. The voting period starts now and lasts for up to one week, or > until the outcome is no longer in doubt. > >

Bug#830344: How should the TC help with a project roadmap?

Margarita Manterola writes: > For documentation purposes, I list below my summary of the points that were > raised during the Roadmap BOF. These items are separate and may not > necessarily > all (or even any) need to be true in the implementation adopted. During the > BOF >

Bug#830344: How should the TC help with a project roadmap?

Package: tech-ctte User: tech-c...@packages.debian.org Mehdi has proposed that the TC be involved in some fashion with a "project roadmap". Some of the TC members met in person at debconf 16 to talk about how that might work. I will attempt to (badly) summarize some of the ideas brought out in

Re: Debian Roadmap discussion ?

Didier 'OdyX' Raboud writes: > [ Unknown signature status ] > Dear TC members, dear DPL, > > as I have reported to you already, I have had multiple discussions > during the course of DebConf so far about the DPL's Debian Roadmap idea > with him; and it would make sense for us

Re: Meeting to plan ctee bof session

Sam Hartman writes: > So, do those of us who are here want to get together possibly tomorrow > and plan our BOF? > I am free any time; I don't know others' constraints. I'm sorry I didn't send mail. I responded in the debconf IRC channel suggesting that we gather after

Re: Proposed Summary of 2016-07-03 breakfast meeting

Sam Hartman writes: > [ Unknown signature status ] > > > Several members of the TC met after breakfast to discuss planning > tomorrow's BOF; discussions diverged into general TC issues. Thanks for writing these notes up; they seem to capture the salient points of the

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

Margarita Manterola writes: > I call for votes on the following resolution with regards to #846002: I vote A > FD. -- -keith signature.asc Description: PGP signature

Bug#836127: Call for Votes for new CTTE Member

Philip Hands writes: > ===BEGIN > > The Technical Committee recommends that David Bremner be > appointed by the Debian Project Leader to the Technical Committee. > > A: Recommend to Appoint David Bremner > B: Further Discussion > > ===END I vote A > B -- -keith

Bug#860520: Voting for TC Chair

Didier 'OdyX' Raboud <o...@debian.org> writes: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A: Keith Packard > B: Didier Raboud > C: Tollef Fog Heen > D: Sam Hartman > E: Phil Hands > F: Margarita Manterola > G: David B

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

Tollef Fog Heen writes: > R: Approve resolution and repeal the CTTE decision from 2012-07-12. > F: Further Discussion I vote R > F -- -keith signature.asc Description: PGP signature

Bug#865485: Voting for TC Chair

Didier 'OdyX' Raboud <o...@debian.org> writes: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A: Keith Packard > B: Didier Raboud > C: Tollef Fog Heen > D: Sam Hartman > E: Phil Hands > F: Margarita Manterola > G: David

Bug#836127: Call for Votes for new TC member

Didier 'OdyX' Raboud writes: > I call for votes on the following ballot to fill a vacant seat in the TC. The > voting period starts immediately and lasts for up to one week, or until the > outcome is no longer in doubt (§6.3.1). > > ===BEGIN > The Technical Committee

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: > This has gone far enough. I would like to remind you of Constitution > 6.3(5) Here's what I prefaced my first remark with: (speaking as a Debian user, not as a TC member) Perhaps I should have added this to each message I sent? --

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: (speaking as a Debian user, not as a TC member) > I'm afraid don't really want to do the work of writing a better UI. > But I have provided a simple patch which at least makes the behaviour > safe. Would it be sufficient to simply stop

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: > But I should be able to use the same laptop to (1) control my machine > tools or talk to my rpi or whatever (2) go online with a usb mobile > modem when I'm out of the house. Possibly even simultaneously. That requires fixing the package

Bug#877024: modemmanager should ask before messing with serial ports

Ian Jackson writes: > Also, AIUI modemmanager contains code to do things with the new-style > MBIM dongles (which can also be done with the cli tools in > mbim-utils). But I definitely wouldn't suggest disabling its ability > to work with AT-command modems, as

Bug#877024: modemmanager should ask before messing with serial ports

Sam Hartman writes: > Have I got that right? Yes, I think you have summarized the issue accurately. > However, for Debian and for the Technical committee, we need to consider > what experience we want to give all our users and as a result value > damage caused by false

Bug#877024: Modemmanager probing of unknown Devices

Ian Jackson writes: > I intend to carry on and try to help do the Debian part of this, with > NMUs as seem appropriate. My earlier email suggesting an upload to > experimental is part of that. If the modemmanager maintainers would > like to step in then that

Bug#880014: #880014: Call for Votes for new TC member

Didier 'OdyX' Raboud writes: > ===BEGIN > The Technical Committee recommends that Gunnar Wolf be > appointed by the Debian Project Leader to the Technical Committee. > > G: Recommend to Appoint Gunnar Wolf > F: Further Discussion > ===END I

Bug#978636: move to merged-usr-only?

Simon McVittie writes: > Should we be more specific than this in what we vote on, to avoid > later having to adjudicate between developers who say that a particular > implementation is or isn't merged-usr? I think that and a transition plan are both key to this project. I recently installed