Bug#822803: Call for votes for new TC member

* Didier 'OdyX' Raboud (o...@debian.org) [160705 10:03]: > 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. > > ===BEGIN > > The

Bug#741573: [CTTE #741573] Debian Menu System

* Keith Packard (kei...@keithp.com) [150904 07:27]: > Vincent Cheng writes: > > > Does this mean that packages providing both a .desktop and a Debian > > menu file are immediately RC-buggy as of now (i.e. is "shall not" > > equivalent to "must not" or "should not" in

Bug#741573: CFV: Debian Menu Systems

Hi, I vote D > A > Z > B > C. (B is below Z because I don't think it ended in consensus. For D enough had been said by others so I'm not going to repeat it - I think it's the right decision so I'm voting this way.) Andi

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

Hi, unfortunatly in this particular week my preferences are way different then usual. So I have to submit two votes: For default meetings: L M (K,N) O B C (A,D) E G H (F,I) J Z For this week: G H (F,I) J B C (A,D) E Z L M (K,N) O Andi * Don Armstrong

Re: Scheduling CTTE Meetings

* Don Armstrong (d...@debian.org) [150317 19:50]: On Tue, 10 Mar 2015, Don Armstrong wrote: Given that we have new members, if anyone has a conflict with that time slot, and would prefer that it was moved, I've created a dudle poll which can be used to vote:

Re: Scheduling CTTE Meetings

* Sam Hartman (hartm...@debian.org) [150318 18:48]: Andreas == Andreas Barth a...@ayous.org writes: Andreas * Don Armstrong (d...@debian.org) [150317 19:50]: On Tue, 10 Mar 2015, Don Armstrong wrote: Given that we have new members, if anyone has a conflict

Re: Call for Votes for new CTTE Chairman

* Sam Hartman (hartm...@debian.org) [150311 13:18]: So, I don't feel that I have the information I need to make an informed decision on this issue, so I won't be able to cast a ballot. Fortunately, it doesn't matter, except for a couple day delay. You could vote: Andi -- To

Re: Call for Votes for new CTTE Chairman

* Tollef Fog Heen (tfh...@err.no) [150311 23:14]: ]] Sam Hartman Andreas == Andreas Barth a...@ayous.org writes: Andreas * Sam Hartman (hartm...@debian.org) [150311 13:18]: So, I don't feel that I have the information I need to make an informed decision on this issue

Re: Call for Votes for new CTTE Chairman

not possible as the constitution says that all members are automatically nominated. === BEGIN The Technical Committee Chairman should be: A: Don Armstrong B: Andreas Barth C: Steve Langasek D: Keith Packard E: Didier Raboud F: Tollef Fog Heen G: Sam Hartman

Re: Bug#769972: Call for Votes for new CTTE Members

* Don Armstrong (d...@debian.org) [150304 17:39]: For ease of voting, I have included all three separate ballots in a single message. ===BEGIN The Technical Committee recommends that Sam Hartman (hartmans) be appointed by the Debian Project Leader to the Technical Committee. A:

Bug#769972: New CTTE members

* Don Armstrong (d...@debian.org) [141118 02:39]: On Mon, 17 Nov 2014, Bdale Garbee wrote: Works for me. I like the start considering wording, too, as opposed to closing the call for nominations. Good thought. very nice indeed. OK. I've written the draft of this here:

Re: new committee members

* Bdale Garbee (bd...@gag.com) [141117 20:59]: I would like to propose that we issue a call for nominations to the project, similar to the one we used last time. I'd like to do that this week. We can discuss here by email and/or in our IRC meeting on the 4th issues like what we should look

Bug#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)

* Ian Jackson (ijack...@chiark.greenend.org.uk) [141105 17:39]: I am calling for votes on the text below: Y (override, swap dependencies, requires 3:1) FD I vote Y, FD (with the remark that Y doesn't make a decision on does debian want to change the default on upgrades but just

Bug#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)

* Matthias Klumpp (matth...@tenstral.net) [141112 13:21]: 2014-11-12 12:28 GMT+01:00 Andreas Barth a...@ayous.org: * Ian Jackson (ijack...@chiark.greenend.org.uk) [141105 17:39]: I am calling for votes on the text below: Y (override, swap dependencies, requires 3:1) FD I vote

Bug#762194: Call for Votes (re automatic switching)

* Ian Jackson (ijack...@chiark.greenend.org.uk) [141102 19:24]: Y. Clarify decison and invite non-auto-switching proposals FD. Further discussion I vote Y, FD. Thanks. Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble?

Bug#681419: Alternative dependencies on non-free packages in main: Call for Votes

* Steve Langasek (vor...@debian.org) [140803 04:00]: As previously agreed in the IRC meeting, I call for votes on this question with the following ballot options: A non-free packages as non-default alternatives should not be prohibited in main B non-free packages should always be

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

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.

Bug#746715: Shocking read ...

* Kurt Roeckx (k...@roeckx.be) [140504 01:03]: On Sat, May 03, 2014 at 06:53:29PM +0100, Ian Jackson wrote: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and

Bug#746715: the foreseeable outcome of the TC vote on init systems

* Bdale Garbee (bd...@gag.com) [140503 01:54]: Steve Langasek vor...@debian.org writes: Package: tech-ctte An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are

Bug#717076: libjpeg draft resolution

* Kurt Roeckx (k...@roeckx.be) [140322 01:39]: On Fri, Mar 21, 2014 at 11:38:15PM +, Ian Jackson wrote: In general I worry that your interpretation of resolution texts focuses far too much on the exact words used, and far too little on the substance of the underlying issues. In

Bug#717076: libjpeg draft resolution

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140322 00:39]: (resending because of some 8-bit header damage) Kurt Roeckx writes (Bug#717076: libjpeg draft resolution): So if you really want to prevent using a supermajority, I suggest you write is so that you at least don't mention the

Bug#636783: TC constitutional issues

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140228 12:15]: Andreas Barth writes (Bug#636783: TC constitutional issues): * Ian Jackson (ijack...@chiark.greenend.org.uk) [140227 19:27]: * 2:1 supermajority for TC overrides should be abolished (seems we are probably agreed

Bug#636783: TC constitutional issues

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140227 19:27]: * 2:1 supermajority for TC overrides should be abolished (seems we are probably agreed on this - speak now if not) I prefer if any decision to override the TC is statistically safe, i.e. not just one vote above 50%. For the

Bug#727708: Call for Votes on init system coupling

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 19:06]: 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 Advice: sysvinit compatibility in jessie and multiple init support FD Further

Bug#727708: init system coupling draft CFV

* Russ Allbery (r...@debian.org) [140221 06:15]: This includes the change I proposed to Andreas, although unfortunately Andreas hasn't had a chance to respond on whether that addressed his objection. It also makes it clearer that the point about not offering advice past jessie only applies to

Bug#727708: init system coupling etc.

* Russ Allbery (r...@debian.org) [140219 19:24]: Andreas Barth a...@ayous.org writes: * Russ Allbery (r...@debian.org) [140214 04:36]: That's a much stronger statement than we've made about support for the non-Linux ports in the past, where they're treated at most like another release

Bug#727708: init system coupling etc.

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:37]: Andreas Barth writes (Bug#727708: init system coupling etc.): Russ Allbery (r...@debian.org) [140219 19:24]: How does this sound to you? Packages should normally support the default init system on all

Bug#727708: init system coupling etc.

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]: Andreas Barth writes (Bug#727708: init system coupling etc.): Russ Allbery (r...@debian.org) [140219 19:24]: So I propose to change the text: The Technical Committee offers no advice at this time on requirements

Bug#727708: init system coupling etc.

* Russ Allbery (r...@debian.org) [140214 04:36]: Andreas Barth a...@ayous.org writes: * Russ Allbery (r...@debian.org) [140212 19:00]: Packages should normally support the default Linux init system. There I would drop the word Linux here - Packages should support our default init

Bug#727708: Thoughts/Summary on the init-system

* Andreas Metzler (ametz...@bebt.de) [140119 19:18]: could you provide a little bit of background why you consider both Systemd on Linux, openrc/sysv-rc on non-Linux and Upstart everywhere viable long-term but not systemd on Linux and upstart on !Linux? Because upstart won't survive Debians

Re: Bug#727708: init system coupling etc.

* Russ Allbery (r...@debian.org) [140212 19:00]: Packages should normally support the default Linux init system. There I would drop the word Linux here - Packages should support our default init systems. are some exceptional cases where lack of support for the default init system

Bug#727708: init system coupling etc.

* Colin Watson (cjwat...@debian.org) [140213 19:09]: To start with, I therefore propose the following amendment to L. I think it is no weaker except in ways that we would agree were in fact OK if we found ourselves needing to rule on them specifically, and this addresses points that people

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

* Bdale Garbee (bd...@gag.com) [140208 20:50]: I expect that Debian can and should continue to support multiple init systems for the foreseeable future. I also believe that Debian can and should take an active role working with upstream projects on software that is important to us, such as

Bug#727708: Init system GR override call for votes

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140209 20:57]: 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

Bug#727708: Init system coupling call for votes

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140209 20:51]: 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

Re: Deposing the chairman of the Technical Committee

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140209 20:28]: Ian Jackson writes (Deposing the chairman of the Technical Committee): AFAICT from the constitition it is not possible to immediately start a vote on the chairmanship of the TC, unless the post is vacant. Arguably, this is a

Bug#727708: Call for votes on init system resolution

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140205 17:39]: Ian Jackson writes (Bug#727708: package to change init systems): I now intend to do the CFV at 16:30 UTC on Wednesday. I hereby call for votes on my previously proposed resolution and amendments. All the options require a

Bug#727708: Call for votes on init system resolution

* Steve Langasek (vor...@debian.org) [140205 18:45]: I think whichever option wins on this ballot, if the TC leaves the discussion here it will be a bad outcome for Debian because it leaves maintainers without clear guidance about how to avoid fragmenting the archive. What would you like to

Bug#727708: Call for votes on init system resolution

* Kurt Roeckx (k...@roeckx.be) [140205 21:09]: On Wed, Feb 05, 2014 at 04:33:57PM +, Ian Jackson wrote: Ian Jackson writes (Bug#727708: package to change init systems): I now intend to do the CFV at 16:30 UTC on Wednesday. I hereby call for votes on my previously proposed resolution

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

* Bdale Garbee (bd...@gag.com) [140125 19:01]: Therefore, I call for votes on the following ballot. If any of you feel that this is the wrong way to proceed, feel free to vote further discussion above all other options. I would appreciate votes from all TC members on this ballot as soon as

Bug#727708: init system discussion status

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140120 12:27]: Keith Packard writes (Re: Bug#727708: init system discussion status): I feel that having the Debian community endorse software where a CLA is involved will tacitly encourage developers to enter into those agreements so that

Bug#727708: The tech ctte isn't considering OpenRC at all

* Thomas Goirand (z...@debian.org) [140119 10:15]: Unfortunately, it seems it's going to be the way OpenRC will be evaluated: because some people *pretended* that OpenRC wouldn't fit the bill, it's just discarded without even having a look at how it works, its features, and its implementation.

Bug#727708: Thoughts/Summary on the init-system

Hi together, first of all, sorry for being so late to this party. I'll start with describing a few facts, observations and thoughts, and come to my conclusions at the end of this mail. I don't write references at places where I believe had already sufficient coverage by others and/or are more or

Bug#727708: Init system resolution open questions

* Russ Allbery (r...@debian.org) [140118 05:15]: Steve Langasek vor...@debian.org writes: I don't believe we need to know the answer to these questions to know that Ian's requirement is a correct one. If we are saying that packages cannot drop their sysvinit scripts in jessie in order to

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

* Russ Allbery (r...@debian.org) [131219 04:09]: Ian Jackson ijack...@chiark.greenend.org.uk writes: systemd supports the non-forking daemon too. Only, instead of raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an environment variable, connect to it, and send a special

Bug#727708: systemd as cgroup writer (was: Bug#727708: systemd jessie - jessie+1 upgrade problems)

* Steve Langasek (vor...@debian.org) [131220 16:57]: The design which claims this role for systemd-as-pid-1, and which does not adequately address use cases of other existing cgroups consumers in the ecosystem (lmctfy, lxc) is broken by design. Having a single cgroup writer in userspace is

Re: Call for votes re new member for the Technical Committee

* Ian Jackson (ijack...@chiark.greenend.org.uk) [131122 13:30]: Ian Jackson writes (New member for the Technical Committee - formal proposal): In two weeks' time (say, 2013-11-21 14:00Z) I will call for a vote on all of the names put forward by TC members. Sorry about the delay. Here

Bug#727708: Init systems: arguments for the CTTE

* Bdale Garbee (bd...@gag.com) [131028 18:51]: Josselin Mouette j...@debian.org writes: While it is (and can remain) possible, just like in the NM case, to install it without systemd and lose functionality, I think it is unreasonable to ask for a default GNOME installation without it.

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

* Thijs Kinkhorst (th...@debian.org) [131106 12:51]: Nonetheless, that's not relevant here. There are several likely candidates in existence, so the choice will not be to use something existing versus implementing from scratch; the choice will be between existing projects, and given that, the

Re: Picking a new member - process

* Don Armstrong (d...@debian.org) [131106 23:41]: I'm OK with voting on the entire slate of nominees who were willing to serve, even if that means that some might be ranked below FD, but I would accept nominees telling the CTTE to do otherwise. If we vote only on those who are proposed here by

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

* Russ Allbery (r...@debian.org) [131104 18:21]: Carlos Alberto Lopez Perez clo...@igalia.com writes: Regarding the development force behind each project, I find the following comparison at Ohloh very illustrative

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

* Russ Allbery (r...@debian.org) [131102 04:12]: If Canonical *is* the sole upstream, the upstream future here is troubling to me, particularly given Canonical's current strategic direction towards Unity. To give a specific example of the sort of thing that I'm worried about, suppose that

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

* Russ Allbery (r...@debian.org) [131106 01:21]: We'll want to look at both sides of that question, and try to understand how much work like that is potentially on the horizon with the various choices. Yes, and I hope that all potential init systems add appropriate information to their

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

* Russ Allbery (r...@debian.org) [131031 02:19]: Theodore Ts'o ty...@mit.edu writes: On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init

Bug#727708: FYI: upstream’s take

* Russ Allbery (r...@debian.org) [131029 03:15]: Michael Stapelberg stapelb...@debian.org writes: my apologies for not replying to any messages within the thread, but I think my mail is orthogonal to the other messages. Lennart Poettering wrote about the systemd upstream point of view

Bug#681419: Alternative main-non-free dependencies text

* Stefano Zacchiroli (z...@debian.org) [130629 09:23]: On Thu, Jun 27, 2013 at 04:01:21PM +0100, Ian Jackson wrote: 8. The Technical Committee resolves that alternative dependencies of the form Depends: package-in-main | package-in-non-free constitute a non-release-critical

Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit

* Ian Jackson (ijack...@chiark.greenend.org.uk) [130416 12:47]: Goswin von Brederlow writes (Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit): On Mon, Apr 15, 2013 at 01:34:25PM +0100, Ian Jackson wrote: You should refer to the TC when it

Bug#698556: Please override isdnutils maintainer's decision to not fix the broken isdnutils package in wheezy

* Andreas Barth (a...@ayous.org) [130227 08:01]: * Andreas Barth (a...@ayous.org) [130224 18:43]: Whereas 1. The technical committee was asked to overrule the decision of the isdnutils maintainer to remove the creation of devices (see #698556). 2. There is a tested patch ready

Bug#698556: Please override isdnutils maintainer's decision to not fix the broken isdnutils package in wheezy

* Andreas Barth (a...@ayous.org) [130227 08:01]: * Andreas Barth (a...@ayous.org) [130224 18:43]: Whereas 1. The technical committee was asked to overrule the decision of the isdnutils maintainer to remove the creation of devices (see #698556). 2. There is a tested patch ready

Bug#698556: Please override isdnutils maintainer's decision to not fix the broken isdnutils package in wheezy

* Andreas Barth (a...@ayous.org) [130221 08:55]: * Bdale Garbee (bd...@gag.com) [130221 07:07]: Good point. Take my advice as being a post-wheezy suggestion, until/unless the kernel and udev get the device entries for ISDN right. Ok. That sounds as we seem to have consensus now about what

Bug#698556: Please override isdnutils maintainer's decision to not fix the broken isdnutils package in wheezy

* Don Armstrong (d...@debian.org) [130224 19:25]: On Sun, 24 Feb 2013, Russ Allbery wrote: Andreas Barth a...@ayous.org writes: Comments? Yup, looks right to me. Yeah, I don't see a problem on this either. ok. I plan to call for vote than on Tuesday (morning or evening UTC

Bug#698556: Please override isdnutils maintainer's decision to not fix the broken isdnutils package in wheezy

* Bdale Garbee (bd...@gag.com) [130221 07:07]: Christoph Biedl debian.a...@manchmal.in-ulm.de writes: Adding a dependency on makedev will work, but since the makedev package is long orphaned and there's rarely any reason to have it installed any more, I personally wonder if it wouldn't be

Re: Bug#699808: tech-ctte (CFV): syslinux vs the wheezy release

* Ian Jackson (ijack...@chiark.greenend.org.uk) [130208 12:31]: Thanks for the feedback. I'm calling for a vote on the resolution below. It's unchanged except that I fixed the paragraph numbering to not have two para.9s. The options are: Y Revert syslinux in unstable, overruling

Bug#698556: Processed: Please override isdnutils maintainer's decision to not fix the broken isdnutils package in wheezy

Hi, * Debian Bug Tracking System (ow...@bugs.debian.org) [130120 13:55]: clone 609736 -1 Bug #609736 [isdnutils-base] isdn device nodes are no longer created Bug 609736 cloned as bug 698556 I already discussed about this topic on the original bug report. Summarizing: 1. I think packages

Re: Bug#688772: gnome Depends network-manager-gnome

* Tollef Fog Heen (tfh...@err.no) [121214 08:50]: ]] Steve Langasek - Installing the gnome or the NM package must not cause the network to break on upgrade, even temporarily, under any circumstances. Is this a requirement for other network-providing packages as well? If so,

Bug#688772: Call for votes for resolving #688772 [gnome Depends network-manager-gnome]

* Don Armstrong (d...@debian.org) [121213 20:07]: I'd like to call for votes to resolve #688772 with the following options, with F as further discussion. Both options A and B require a 3:1 majority, as they overrule the gnome maintainers; Option C does not. I vote BCAF Andi -- To

Bug#688772: gnome Depends network-manager-gnome

Hi, * Jordi Mallach (jo...@debian.org) [121113 10:29]: [...] First of all, thanks for your mail. I think it shows a good direction to move on (though I'm not convinced that not running n-m is more appropriate than not installing it, but well, YMMV.) NetworkManager and static interface

Bug#688772: gnome Depends network-manager-gnome

* Ian Jackson (ijack...@chiark.greenend.org.uk) [121109 10:51]: There is no technical reason to prefer a situation where the user has n-m installed but disabled to one where they don't have it installed. There _are_ technical reasons why (on systems where n-m's operation is not desired) not

Bug#688772: gnome Depends network-manager-gnome

* Don Armstrong (d...@debian.org) [121108 01:18]: Therefore A 4. We overrule the decision of the meta-gnome maintainers to add a Adependency from gnome to network-manager-gnome; this dependency Ashould be removed for the release of wheezy. B 4. We overrule the decision of the

Bug#688772: gnome Depends network-manager-gnome

* Jeremy Bicha (jbi...@ubuntu.com) [121025 18:51]: On 25 October 2012 12:17, Don Armstrong d...@debian.org wrote: That said, if I'm wrong, and you believe that there is a compromise which would resolve the concerns raised beyond those already presented (status quo with/without release

Bug#688772: gnome Depends network-manager-gnome

* Michael Biebl (bi...@debian.org) [121024 03:57]: On 24.10.2012 03:29, Sam Hartman wrote: Don, in your option 4B, I wonder if it would be a good idea to have the depend be something like g-n-m|wicd|no-network-manager The gnome meta-package certainly won't get an alternative dependency

Re: Bug#573745: Call for votes on Python Maintainer Question

* Don Armstrong (d...@debian.org) [121004 23:09]: I call for a vote on the following resolution to #573745. 7. A The committee resolves that the maintainer of python interpreter A packages in Debian is a team made up of members decided by (and A including) Sandro Tosi mo...@debian.org B

Re: Bug#573745: Initial draft of resolution of the Python Maintainer question

* Steve Langasek (vor...@debian.org) [120929 07:29]: On Fri, Sep 28, 2012 at 03:30:23PM -0400, Michael Gilbert wrote: You can actually check out the sources pretty easily using debcheckout, and as bzr is a distributed VCS, you don't really need a launchpad account to contribute to it.

Re: Abusive and obnoxious behavior

* Josselin Mouette (j...@debian.org) [120925 18:37]: I’ve just read Ian Jackson’s latest proposal: [...] If you mean by your subject that the words This should be in compliance with the Crusade. in a changelog and changes file are not acceptable: You are absolutly right. Andi -- To

Re: Bug#688772: gnome Depends network-manager-gnome

* Ian Jackson (ijack...@chiark.greenend.org.uk) [120925 17:51]: Tollef Fog Heen writes (Re: Bug#688772: gnome Depends network-manager-gnome): Ian Jackson 10. We therefore formally reprimand Josselin Mouette. We consider his behaviour deliberately obstructive and obtuse. I

Bug#688772: gnome Depends network-manager-gnome

* Ian Jackson (ijack...@chiark.greenend.org.uk) [120925 19:33]: Andreas Barth writes (Re: Bug#688772: gnome Depends network-manager-gnome): Though I think that the change is against our decision, I'd prefer dropping that line from our next decision. OK. Do you have an opinion about

Bug#688772: gnome Depends network-manager-gnome

* Russ Allbery (r...@debian.org) [120925 21:30]: I'm wondering if we should just document the change to the gnome metapackage in the release notes. I think there's really something to be said for treating this as a compromise position. In case the packages stay as they are right now, I think

Bug#681834: Call for votes on network-manager, gnome

* Ian Jackson (ijack...@chiark.greenend.org.uk) [120911 15:10]: Russ Allbery writes (Re: Bug#681834: network-manager, gnome, Recommends vs Depends): Here's what I now have: I asked for comments and no-one had any. So I hereby call for votes on the resolution below. The options are:

Re: Bug#681783: Call for votes on Recommends and metapackages

* Ian Jackson (ijack...@chiark.greenend.org.uk) [120814 14:48]: I'm calling for a vote on my proposal for a disposal of #681783, re Recommends and particularly metapackages. The options are: A Recommends policy is correct, clarification would be useful F Further discussion. I vote

Re: Call for votes on node+nodejs

* Steve Langasek (vor...@debian.org) [120709 01:32]: I'm calling for votes on the below resolution on the Node/NodeJS question. === Resolution === The Technical Committee reaffirms the importance of preventing namespace collisions for programs in the distribution, while recognizing that

Re: periodic tech-ctte IRC meetings

* Don Armstrong (d...@debian.org) [120509 22:58]: As only Russ and myself have responded, I'm guessing that using Doodle isn't going to work particularly well for scheduling: How about I try scheduling by fiat: Wed May 30 19:00:00 UTC 2012 Wed May 30 12:00:00 PDT 2012 date -d

Re: periodic tech-ctte IRC meetings

* Don Armstrong (d...@debian.org) [120511 02:14]: On Fri, 11 May 2012, Ian Jackson wrote: Don Armstrong writes (Re: periodic tech-ctte IRC meetings): On Fri, 11 May 2012, Ian Jackson wrote: I'm afraid I can't make that time on any Wednesday. If we're looking at that kind of time of

Bug#573745: Please decide on Python interpreter packages maintainership

* Stefano Zacchiroli (lea...@debian.org) [120428 10:45]: On Fri, Apr 27, 2012 at 08:20:33PM -0700, Russ Allbery wrote: This does, to me, raise the question of whether Jakub should be listed as a separate option, or whether there's no meaningful distinction between a maintenance team formed

Bug#640874: leave: debian/rules is not a Makefile

* Russ Allbery (r...@debian.org) [120326 20:58]: Russ Allbery r...@debian.org writes: Based on Ian's last response, I think the ballot has two options plus further discussion, since I'm quite sure that we're not going to outlaw dh: A. debian/rules is not required to be a makefile,

Bug#629385: Request for TC to rule on a course of action for supporting build-arch

* Russ Allbery (r...@debian.org) [120320 21:48]: Hearing no objections, I call for a TC vote on the following ballot: A. dpkg-buildpackage, when doing a binary-only build (-B), should probe the package with make -qn to see if the build-arch target appears to be implemented. If so, it

Bug#636783: proposed constitution fix for super-majority within the tech ctte

* Ian Jackson (ijack...@chiark.greenend.org.uk) [120320 13:01]: This would be in the form of a TC resolution along these lines: For the purposes of accepting or rejecting amendments to this GR proposal, according to Constitution A.1(2), we delegate to name the power to accept

Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte

* Russ Allbery (r...@debian.org) [120319 05:10]: Ian Jackson ijack...@chiark.greenend.org.uk writes: Andreas Barth writes: As I got no further comments from other people of the tech ctte, this can only mean that everyone agrees with this version, or is not interessted. I think

Bug#573745: Please decide on Python interpreter packages maintainership

* Russ Allbery (r...@debian.org) [120319 06:00]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745#335 B. The Technical Committee have been petitioned to decide on the maintainership of the python packes. We agree with the substance of the complaint, but do not feel able to

Bug#573745: Please decide on Python interpreter packages maintainership

* Russ Allbery (r...@debian.org) [120319 22:27]: Andreas Barth a...@ayous.org writes: How about: BC. The Technical Committee have been petitioned to decide on the maintainership of the python packes. We agree with the substance of the complaint, but do not feel able

Bug#658341: Call for Vote: upload of multi-arch enabled dpkg (in time for wheezy)

* Bdale Garbee (bd...@gag.com) [120202 15:16]: A. While recognizing the substantial benefits of thorough code review, the Technical Committee believes the goal of multiarch support in the Debian wheezy release is sufficiently important as to warrant accepting the current draft

Bug#587956: Call for vote on cleanup bindv6only

* Andreas Barth (a...@not.so.argh.org) [110730 17:15]: as I think after release of squeeze it is just to late to cleanup bindv6only, so I intend to call for vote with the following options: 1. We don't override the maintainers decision. 2. Further discussion. As there was no additional

Bug#587956: proposed call for vote on cleanup bindv6only

Hi, as I think after release of squeeze it is just to late to cleanup bindv6only, so I intend to call for vote with the following options: 1. We don't override the maintainers decision. 2. Further discussion. Any more options that should be part of the vote? Otherwise, I'd just intend to call

Re: Bug#629385: Request for TC to rule on a course of action for supporting build-arch

* Steve Langasek (vor...@debian.org) [110612 01:09]: On Tue, Jun 07, 2011 at 09:41:18AM +0200, Raphael Hertzog wrote: --- Turn on direct use of debian/rules build-arch unless the package seems to be missing the target according to make -qn. In that case output a warning that asks the

Re: Request for TC to rule on a course of action for supporting build-arch

* Tollef Fog Heen (tfh...@err.no) [110607 11:14]: ]] Steve Langasek Hi, | 4) Turn on direct use of 'debian/rules build-arch' on the autobuilders for | all packages in unstable and experimental immediately, with no fallback | if the target does not exist; requires a corresponding

Re: Request for TC to rule on a course of action for supporting build-arch

* Russ Allbery (r...@debian.org) [110606 22:05]: Andreas Barth a...@not.so.argh.org writes: Option 1 also implies forcing debian/rules to be a Makefile, which is think is sensible. Policy already requires this. The only package in the archive for which this is not already the case

Re: Bug#573745: ping

* Russ Allbery (r...@debian.org) [110305 20:57]: The problem that I have with the curent situation is that kicking Matthias to the curb seems to be a requirement for a resolution, and that makes me really uncomfortable. I'm not, to note, saying I'm flatly opposed to that, just that it makes

Bug#587886: future of maintaining of the bootloader LILO

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Don Armstrong (d...@debian.org) [101129 12:06]: [for reference: A. lilo should be removed. In the meantime, William is to be sole maintainer of lilo. His promised request to the ftp team to remove lilo should be honoured, after

Re: Bug#587886: future of maintaining of the bootloader LILO

* Ian Jackson (ijack...@chiark.greenend.org.uk) [101130 19:31]: Kurt Roeckx writes (Re: Bug#587886: future of maintaining of the bootloader LILO): I'd like to point out that neither of your votes are signed. This is true. But there is no requirement for TC members' votes to be signed.

Bug#573745: Things have changed significantly for the better

* Sandro Tosi (mo...@debian.org) [100705 23:28]: On Mon, Jul 5, 2010 at 21:46, Piotr Ożarowski pi...@debian.org wrote: Here's my proposal: * Ask Barry to join Matthias (and Matthias to accept Barry) as adding Barry (if he accepts, of course) to the maints of python would be a huge

  1   2   >