Bug#727708: Call for votes on init system resolution

Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"): > On Fri, Feb 07, 2014 at 02:04:42PM +, Ian Jackson wrote: > > I have added the following texts to the drafts in git: > > > > + == introduction (all versions except GR) == > >

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

Bdale Garbee writes ("call for votes on default Linux init system for jessie"): > I have carefully considered Ian's current proposal for a process and > schedule to reach a next ballot on the init system issue, and do not > believe it is the best way for us to proceed. This unannounced CFV is an a

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

Keith Packard writes ("Re: call for votes on default Linux init system for jessie"): > Let's finish that vote then and move on. Once again Bdale has proposed a vote on his own motion. However, my own proposal was on the table and has not been withdrawn. Bdale chose to put forward his ballot ent

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. However, I need to work with what I have. I hereby propose the following TC resolution. The Technical Committee has lost confidence i

Re: Deposing the chairman of the Technical Committee

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. However, I need to work with

Re: Deposing the chairman of the Technical Committee

Ian Jackson writes ("Re: Deposing the chairman of the Technical Committee"): > Ian Jackson writes ("Deposing the chairman of the Technical Committee"): > > I hereby propose the following TC resolution. > > > > The Technical Committee has lost confide

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

I hereby propose the L versions from git: == dependencies rider version L (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 acce

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

Ian Jackson writes ("Init system Call for Votes, Ian's drafts"): > I hereby propose the L versions from git: > > == dependencies rider version L (Loose coupling) == > > Software outside of an init system's implementation may not require > a spec

Re: Deposing the chairman of the Technical Committee

Ian Jackson writes ("Re: Deposing the chairman of the Technical Committee"): > Ian Jackson writes ("Re: Deposing the chairman of the Technical Committee"): > > I hereby call for votes. > > I vote >1. Y (TC has lost confidence in chairman) >

Bug#727708: Init system coupling call for votes

Ian Jackson writes ("Init system coupling call for votes"): > 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 mult

Bug#727708: Init system coupling call for votes

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 future; we continue to welcome contributions of support for a

Bug#727708: Init system GR override call for votes

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 that position statement entirely replace the substanc

Bug#727708: Init system GR override call for votes

Ian Jackson writes ("Init system GR override call for votes"): > 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 &

Taking a few days' holiday from the TC

Following my most recent emails, three separate well-meaning people have suggested that perhaps I should step away from the computer for a bit. One correspondent said it looked like I had "gone postal". It is true that I am absolutely furious. Livid. I can't describe in words how angry I am. I

test

do not reply -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21239.57931.522878.612...@chiark.greenend.org.uk

test

Apparently I can't write filter files either -- Ian Jackson personal email: These opinions are my own.http://www.chiark.greenend.org.uk/~ijackson/ PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657 -- To UNSUBSCRIBE, email to debian

Hello again

I've undone the mail filtering that I did on Sunday and caught up on what seemed like the most important emails. I'm still sorry that I reacted the way I did but I still think my anger is completely justified. I don't intend to get into very much discussion here. I'm aware that I'm not at my mos

Bug#727708: init system coupling etc.

I see that the resolutions I proposed on Sunday have been voted down (or are likely to be voted down). Without the wider scope of the GR separately rider (which looks unlikely to pass), my T-vs-L individual resolution is actively harmful because it's not GR-overrideable in itself so: FORMAL ACTIO

Bug#727708: init system coupling etc.

Lucas Nussbaum writes ("Bug#727708: init system coupling etc."): > I must admit that I only followed this part of the discussion from a > distance. Fair enough. > On 12/02/14 at 14:08 +, Ian Jackson wrote: > > [loose coupling] > > > >Software outsi

Bug#727708: init system coupling etc.

Lucas Nussbaum writes ("Bug#727708: init system coupling etc."): > If you really want to have that discussion now, rather than wait for > actual, concrete problems to discuss, I'd suggest that you build a few > hypothetical scenarios, and discuss them. And then build a resolution > that represents

Bug#727708: init system coupling etc.

Keith Packard writes ("Bug#727708: init system coupling etc."): > I agree with you that this is an important issue which needs to be > resolved within the Debian project. I also want to make it clear that I > support the goal of having the project provide a clear policy statement > about this issue

Bug#727708: init system coupling etc.

Russ Allbery writes ("Bug#727708: init system coupling etc."): > I propose the following text as an amendment to this option. [...] Thanks for your constructive contribution. (As I'm sure you'll understand, I don't agree with it but it is right that you propose something you feel reflects your v

Bug#727708: init system coupling etc.

Noah Meyerhans writes ("Bug#727708: init system coupling etc."): > On Wed, Feb 12, 2014 at 10:35:12PM +, Ian Jackson wrote: > > Yes. I agree that it's vague. I'm open to better and clearer > > suggestions. When I wrote this I was hoping that the policy

Bug#727708: init system coupling etc.

Colin Watson writes ("Bug#727708: init system coupling etc."): > Ian, you said that you don't agree with this amendment. I am guessing > based on your previous statements that you mainly disagree with the > force of it, rather than the substance, but I'm cautious of making > unwarranted inferences

Bug#727708: init system coupling etc.

Colin Watson writes ("Bug#727708: init system coupling etc."): > 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 t

Bug#727708: init system coupling etc.

Josselin Mouette writes ("Bug#727708: init system coupling etc."): > In all cases, it is unacceptable to put the burden of implementing > logind on non-systemd systems on maintainers of packages that just need > the logind interfaces. If it is not available, software such as gdm3 > will depend, dir

Bug#727708: init system coupling etc.

Ansgar Burchardt writes ("Bug#727708: init system coupling etc."): > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that > plans to depend on logind... logind is a red herring because AIUI we already have a technical solution to that. The problem is other things that might be in

Bug#727708: init system coupling etc.

Ian Jackson writes ("Bug#727708: init system coupling etc."): > In the spirit of my response to Noah Meyerhans: > > In general, software may not require a specific init system to be > pid 1. The exceptions to this are as follows: > * alternative in

Bug#727708: init system coupling etc.

Josselin Mouette writes ("Bug#727708: init system coupling etc."): > Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit : > > Depending on how this is written, it may depend on the package providing > > journalctl or it may depend on some shared library that implements the > > journal re

Bug#727708: init system coupling etc.

Ian Jackson writes ("Bug#727708: init system coupling etc."): > Ian Jackson writes ("Bug#727708: init system coupling etc."): > > In the spirit of my response to Noah Meyerhans: > > > > In general, software may not require a specific init system to

Bug#727708: init system coupling etc.

Russ Allbery writes ("Bug#727708: init system coupling etc."): > Uwe Storbeck writes: > > On Feb 12, Russ Allbery wrote: > > >> Packages should normally support the default Linux init system. > > [..] > >> Package maintainers are strongly encouraged to merge any contributions > >> for

Bug#727708: init system coupling etc.

Keith Packard writes ("Re: Bug#727708: init system coupling etc."): > The discussions held within the context of the default init bug were > fruitful, and without rancor, which makes me hopeful that the project > membership can drive this issue to consensus in the near future through > the usual po

Bug#727708: init system coupling etc.

Andreas Barth writes ("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. For th

Bug#727708: init system coupling draft CFV

Here are the options which have been proposed so far, with the proposed amendments incorporated as applicable. You can find the history (with messageids) in the tc git repo. There are curently four options: Ian mark 2 (inclues amendments from Colin and Ian) Keith Russ (includes one thing t

Bug#727708: init system coupling etc.

Steve Langasek writes ("Bug#727708: init system coupling etc."): > On Wed, Feb 19, 2014 at 09:37:50AM -0700, Bdale Garbee wrote: > > That would be good, since I at least have sort of lost track of what you > > think the ballot options will be at this point. > > Likewise, I've lost the thread of wh

Bug#727708: init system coupling etc.

Colin Watson writes ("Bug#727708: init system coupling etc."): > On Thu, Feb 13, 2014 at 06:51:13PM +, Ian Jackson wrote: > > Is this a clearer line to draw ? > > This is largely clearer, thank you, but I find myself tripping over the > repetition of "tolera

Bug#727708: init system coupling etc.

Russ Allbery writes ("Bug#727708: init system coupling etc."): > If you do mean that all packages with init system configuration have to > ship sysvinit scripts, I wish the wording would actually say that. This > potentially matters in the long run. For example, consider a hypothetical > future w

Bug#727708: init system coupling draft CFV

Ian Jackson writes ("Bug#727708: init system coupling draft CFV"): > Here are the options which have been proposed so far, with the > proposed amendments incorporated as applicable. > > You can find the history (with messageids) in the tc git repo. > > There are curen

Bug#727708: init system coupling etc.

I'm writing here in a purely secretarial capacity. Russ Allbery writes ("Bug#727708: init system coupling etc."): > Colin Watson writes: > > I agree. Russ, how about this amendment? Is that a formal proposal ? > > diff --git a/727708_initsystem/coupling-russ.txt > > b/727708_initsystem/coupli

Bug#727708: init system coupling etc.

Ian Jackson writes ("Bug#727708: init system coupling etc."): > Steve Langasek writes ("Bug#727708: init system coupling etc."): > > So I don't think a 24 hour period between draft CfV and CfV is > > adequate here. There have been a lot of proposals discu

Bug#727708: init system coupling etc.

Colin Watson writes ("Bug#727708: init system coupling etc."): > Would it improve things if we added an informative paragraph such as > this? (I'm not necessarily asking whether it would lead you to rank > this option higher, just whether it makes the intent clearer.) > > This policy is intende

Bug#727708: init system coupling draft CFV

Ian Jackson writes ("Bug#727708: init system coupling draft CFV"): > There are curently four options: > > Ian mark 2 (inclues amendments from Colin and Ian) > Keith > Russ (includes one thing that loos like an amendment) These descriptions of the options are

Bug#727708: init system coupling draft CFV

Russ Allbery writes ("Bug#727708: init system coupling draft CFV"): > Ian Jackson writes: > A Advise sysvinit compatibility through jessie, multiple init support > > is the closest I can get (at least right at the moment) to capturing the > nuance of my proposa

Bug#727708: init system coupling draft CFV

Ian Jackson writes ("Re: Bug#727708: init system coupling draft CFV"): > Russ Allbery writes ("Bug#727708: init system coupling draft CFV"): > > is the closest I can get (at least right at the moment) to capturing the > > nuance of my proposal in one line. >

Bug#727708: init system coupling 2nd draft CFV

Here are the options on the table right now: L Software may not depend on a specific init system (Ian "mk2") N No TC resolution on this question at this time (Keith) A Advice: sysvinit compatibility in jessie and multiple init support FD Full texts below. I have improved the formattin

Bug#727708: init system coupling draft CFV

Andreas Barth writes ("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 i

Bug#727708: init system coupling etc.

Keith Packard writes ("Re: Bug#727708: init system coupling etc."): > Ian Jackson 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 softw

Bug#727708: init system coupling draft CFV

Russ Allbery writes ("Bug#727708: init system coupling draft CFV"): > Here is the new draft of my ballot option. I think this addresses all of > the issues that were raised. I didn't rewrite the whole thing to avoid > all the shoulds; I thought about it, but it felt like it made it a bit too > ha

Bug#727708: init system coupling etc.

Andreas Barth writes ("Bug#727708: init system coupling etc."): > So I propose to change the text: > > > > The Technical Committee offers no advice at this time on requirements > > or package dependencies on specific init systems after the jessie > > release. There are too many variabl

Bug#727708: init system coupling etc.

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 > > architectures for which they are built. There are some exceptional >

Bug#727708: init system coupling etc.

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 > > or package dependencies on specific init systems after the je

Bug#727708: init system coupling etc.

Andreas Barth writes ("Re: Bug#727708: init system coupling etc."): > Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]: > > Looking at Russ's draft, he has already made an effectively identical > > change. Russ's wording is: > > > >

Bug#727708: init system coupling etc.

For Andi's version of Russ's text I have written this summary line into the git repo: B Advice: sysvinit compatibility in jessie and multi init, arch, support The difference between Russ's (A) and Andi's (B) is precisely this: < Software should normally support the default init system on

Bug#727708: init system - achieving diversity

I'm taking off my secretarial hat for a moment and presenting a short polemic in favour of my proposal over Russ's (whether as amended by Andi or not). I'm addressing myself primarily to the members of the TC who are in favour of diversity in init systems, and in architectures, and who think that

Bug#727708: init system coupling etc.

Russ Allbery writes ("Re: Bug#727708: init system coupling etc."): > Ian Jackson writes: > > If Russ does not accept this amendment then both A and B will be on > > the ballot. > > I accept this amendment. I have removed the unamended version from the git rep

Bug#727708: init system coupling final draft CFV

Options on the ballot right now: L Software may not depend on a specific init system (Ian "mk2") N No TC resolution on this question at this time (Keith) A Advice: sysvinit compatibility in jessie and multiple init support FD Full texts below. There are no outstanding textual amendmen

Bug#727708: Call for Votes on init system coupling

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 Advice: sysvinit compatibility in jessie and multiple init suppo

Bug#727708: Call for Votes on init system coupling

Ian Jackson writes ("Bug#727708: Call for Votes on init system coupling"): > 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 >

Bug#636783: TC constitutional issues

Briefly, mostly for my own notes: * 2:1 supermajority for TC overrides should be abolished (seems we are probably agreed on this - speak now if not) * FD threshold needs to be >= always, not >. Requirement to get >> 4/8 voting X > FD was exploitable and bad news. * Possible minimum dis

Bug#636783: TC constitutional issues

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 on this - speak now if not) > > I pre

Bug#733452: Init system readiness protocols

Having seen everyone's responses to this, and the TC decision in 727708, I think there is no useful work item represented by this bug. Certainly nothing that should be on the TC's agenda. So I'm closing this clone of 727708, which I made earlier. Thanks, Ian. -- To UNSUBSCRIBE, email to debian

Bug#717076: libjpeg draft resolution

(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 other package > by name but make it more general. Seriously ? > I

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 respec

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 differenc

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

Bug#741573: On menu systems. [and 1 more messages]

Matthias Klumpp writes ("Bug#741573: Two menu systems"): > 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 w

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

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

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

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 cont

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 i

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 compute

Bug#741573: Two menu systems

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

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

Bug#741573: Two menu systems

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

Bug#741573: Two menu systems

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

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

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

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 ev

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 general

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

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

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

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 shoul

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

Russ Allbery writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"): > Steve Langasek writes: > > An Ubuntu developer just brought the following Debian changelog entry to > > my attention: > > > tftp-hpa (5.2-17) experimental; urgency=low > >* Removing upstart hacks,

Re: Scheduling the Next Debian CTTE Meeting

Don Armstrong writes ("Scheduling the Next Debian CTTE Meeting"): > I've fallen behind on my duties, and should have already scheduled a > meeting for April. Since April has nearly fled, I'm going to finalize > the schedule for May instead. > > Currently, the calendar has the next meeting on > da

Bug#746715: Shocking read ...

Thomas Goirand writes ("Bug#746715: Shocking read ..."): > I'm really stoned by reading this bug. Daniel is nicely proposing to > accept patches from Steve, and re-add support for Upstart, and he just > wrote that Steve could have just get in touch. This is backwards. If the maintainer had a prob

Bug#746715: Shocking read ...

Kurt Roeckx writes ("Re: Bug#746715: Shocking read ..."): > 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 &

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

Mehdi Dogguy writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"): > Well, Raphael is not Daniel's friend... fine. But, actually, who > cares? The maintainer should go over those details and simply does > his job. What raphael is trying to explain is that he failed in his

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

Ansgar Burchardt writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"): > Is there still anything left to discuss on tftp-hpa/upstart or could > this issue be closed? The last upload restored support for upstart[1]. > [1]

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

Russ Allbery writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"): > On what grounds do you think it was a mistake? As soon as someone talked > to the maintainer in question and asked them to re-add support, support > was almost immediately re-added. If the TC had said s

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

Daniel Baumann writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"): > 1. syslinux [etc.] > lxc [etc] Daniel, I appreciate that you feel the need to rebut the criticisms that have been made of you. I don't think that's unreasonable. But, I think we should draw a line un

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 currentl

Re: Next CTTE Meeting is date -d 'Thu May 22 17:00:00 UTC 2014' (under 22 hours from now)

Don Armstrong writes ("Next CTTE Meeting is date -d 'Thu May 22 17:00:00 UTC 2014' (under 22 hours from now)"): > The next CTTE meeting is at > > date -d'Thu May 22 17:00:00 UTC 2014' > > in #debian-ctte on irc.debian.org (OFTC). > > The current agenda is in the git repository, and is reprodu

Bug#636783: TC supermajority bug

We discussed this on -project. I have been convinced that my previous approach was wrong. I now think that we should do as follows: * Move the "required majority ratio" test from A.6(3) to the very end, after A.6(8). * Change the test > to >=. * The consequence of not meeting the majorit

Bug#636783: TC casting vote

We have had some discussion about this. No-one seems to have objected to the suggestion that the DPL, rather than the TC chairman, should have a casting vote in TC decisions. I'm therefore intending to roll this up into my TC GR(s). Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.d

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

Ian Jackson writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"): > I do think there is still something for the TC to do here. As Andi > writes, the TC failed to clarify that we expect people to continue to > support multiple init systems. Evidently

Bug#636783: TC minimum discussion period

We have discussed having a minimum discussion period for TC resolutions. I still think this is necessary. I think 72h is about right. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: h

Bug#636783: GR giving advice to TC on overruling

I have concluded that it is not going to be feasible for me to find a wording for an advisory GR which will achieve my objectives. I'm therefore dropping it from my personal todo list. I have removed it from the TC git repo. If someone else wants to pick it up, they'd have my support. Thanks, I

Bug#717076: libjpeg draft resolution

Ondřej Surý writes ("Bug#717076: libjpeg draft resolution"): > I would like to kindly ask if there's anything the rest of us can do > to move this forward, so we have a time for a transition before > next freeze. This was stalled because of an unfortunate interaction with the Project Secretary.

<    5   6   7   8   9   10   11   12   13   >