On Mon, Jan 26, 2015 at 5:49 PM, Don Armstrong wrote:
> On Mon, 26 Jan 2015, Michael Gilbert wrote:
>> Why? Option A, i.e. the only option, is already the status quo, so
>> what's the point?
>
> It affirms the decisions which have been made by the other teams in
&
On Mon, Jan 26, 2015 at 4:22 PM, Steve Langasek wrote:
> On Wed, Dec 10, 2014 at 11:10:10AM -0800, Don Armstrong wrote:
>> I've attached below an initial draft of an option for #762194 for
>> discussion.
>
>> Steve indicated that he wanted to revise/contribute to this option, so I
>> don't believe
On Wed, Dec 10, 2014 at 2:10 PM, Don Armstrong wrote:
> I've attached below an initial draft of an option for #762194 for
> discussion.
>
> Steve indicated that he wanted to revise/contribute to this option, so I
> don't believe we should call for votes until that happens.
>
> ==BEGIN==
>
> In #762
On Wed, Dec 17, 2014 at 10:11 PM, Stephen Lyons wrote:
> Can I offer the view of a concerned end-user here?
>
> I have worries about the proposal to force me to change from a sysV init
> system about which I'm still learning things despite first starting with
> GNU/Linux perhaps twenty years ago, t
On Sun, Feb 9, 2014 at 8:04 AM, Colin Watson wrote:
> I vote UDOFV.
So, this vote effectively gives systemd the win (assuming Bdale opts
for the casting vote).
This trumps the fact that Steve was in the midst of drafting a
potentially agreeable ballot all around, and had stated his
disappointment
On Sat, Feb 8, 2014 at 9:23 PM, Michael Gilbert wrote:
> Instead, none of the important implementation related stuff has been
> discussed.
Correction, a lot of that has been discussed, but there has been no
progress on it due to the distraction on the bigger political problem.
Best wishes
On Sat, Feb 8, 2014 at 9:08 PM, Paul Tagliamonte wrote:
> On Sat, Feb 08, 2014 at 06:56:10PM -0500, Michael Gilbert wrote:
>> Paul, you know I think you're awesome, but you've stirred up a whole
>> lot of trouble here with a questionable motive.
>
> What motive is t
On Sat, Feb 8, 2014 at 7:17 PM, Russ Allbery wrote:
> Look, I've been involved in Policy work for years now. I think I have a
> pretty good intuition for what sort of questions can be dealt with
> usefully in that framework and which ones can't. You're certainly
> entitled to think that I'm wrong
On Sat, Feb 8, 2014 at 6:52 PM, Russ Allbery wrote:
>> But at least it would follow the usual process, and only when
>> consensus does actually fail does the TC need to mediate.
>
> If you're looking for Policy Editors who enjoy running things through a
> process that won't be successful just so th
On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote:
> I understand you think that, and I empathize, but I disagree.
>
> The fact is, I have limited time. If I'm going to focus on making a
> bigger impact with my work, I'm going to stick to dealing with issues
> that effect the most users.
>
> I
On Sat, Feb 8, 2014 at 6:23 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> Why not hammer that out on -policy in public, and only if something goes
>> wrong there, then defer it to the TC?
>
> Because -policy doesn't have a decision-making process other than
> c
On Fri, Feb 7, 2014 at 5:37 PM, Paul Tagliamonte wrote:
> On Fri, Feb 07, 2014 at 02:27:25PM -0800, Steve Langasek wrote:
>> So I don't think any
>> maintainers should feel blocked on this by the lack of a formal vote; I
>> certainly don't think that the conclusion of the vote is the only blocker
>
On Sat, Feb 8, 2014 at 5:56 PM, Russ Allbery wrote:
> Keith Packard writes:
>
>> That is an entirely separate issue. I agree that it is important and
>> needs to be resolved, but the Technical Committee is the wrong place to
>> be designing this policy. We must (by 6.3.5) not engage in design of ne
On Sat, Feb 8, 2014 at 5:55 PM, Joerg Jaspert wrote:
> On 13481 March 1977, Steve Langasek wrote:
>
>> I will note for the record here that a number of DDs have at this point
>> given the TC an ultimatum in private, stating that they will start a GR if
>> the TC does not call for votes within a spe
On Wed, Feb 5, 2014 at 5:05 PM, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
>> I would really like it that you indicated under which power the
>> CTTE is making decisions, and the majority requirements that go
>> with that the options, for all y
On Wed, Feb 5, 2014 at 3:08 PM, Kurt Roeckx wrote:
> 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
On Wed, Feb 5, 2014 at 3:03 AM, Thomas Goirand wrote:
> Hi,
>
> Just a short message to inform everyone that, with the latest sysvinit
> package from Sid (eg: 2.88dsf-47) and the latest OpenRC package from
> Experimental (eg: 0.12.4+20131230-8), then Hurd just boots fine with
> OpenRC! :)
[...]
>
On Mon, Feb 3, 2014 at 11:44 PM, Nikolaus Rath wrote:
> Michael Gilbert writes:
>> On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
>>> So all deferring for another cycle does is leave Debian with annoying
>>> cumbersome init scripts and unsolvable race c
On Mon, Feb 3, 2014 at 9:31 AM, Jonathan Dowland wrote:
> On 03/02/2014 14:17, Michael Gilbert wrote:
>> Hence those TC members that don't want to see its default should be
>> trying to figure out how to get 1 of the 4 to vote something else
>> above systemd.
>
> S
On Mon, Feb 3, 2014 at 1:42 PM, Steve Langasek wrote:
> So all deferring for another cycle does is leave Debian with annoying
> cumbersome init scripts and unsolvable race conditions for another cycle.
Which have already been solved for a long time now. It's not like a
bunch of new sysvinit bugs
I'd like to make one last plea in support of sysvinit, since I see no
compelling reason to rush to something else in time for jessie.
Firstly, it is already much easier to use alternative init systems
since the TC discussion really got going in December. init-select
makes it super easy to swap be
On Sun, Feb 2, 2014 at 1:44 AM, Russ Allbery wrote:
> Cameron Norman writes:
>
>> This is not really what I was interested in. I want a package for each
>> init system (init-systemd, init-upstart, etc.) that uses something like
>> init-select (under the hood) to prompt the user to change the init
>
On Sat, Feb 1, 2014 at 11:25 AM, Steve Langasek wrote:
> On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote:
>> And that does matter a lot, since such claims seem to be the basis
>> of all these "GNOME in jessie needs systemd" or "with multiple init
>> systems, GNOME will need a dependency
On Thu, Jan 30, 2014 at 12:04 PM, Ian Jackson wrote:
>> What would be the effecr if we decided to drop GNOME, because it
>> depends on systemd?
>
> In this hypothetical scenario:
>
> It would be fairly easy for a downstream of Debian to mandate systemd
> for their users, and provide Gnome.
>
> It w
On Tue, Jan 28, 2014 at 9:57 AM, Thorsten Glaser wrote:
> Michael Gilbert dixit:
>
>>Why not avoid impeding progress and just let gnome do what it needs to
>>work the way it wants, which would involve depending on the right
>
> Excuse me, why is GNOME, specifically, bein
On Tue, Jan 28, 2014 at 12:42 PM, Adrian Bunk wrote:
> For anyone intending to make Debian the laughingstock of the open source
> world, here is a good opportunity:
>
> Debian decides that Upstart is the default init system for jessie,
> but it's default desktop GNOME forces the installation of
On Tue, Jan 28, 2014 at 8:51 AM, Don Armstrong wrote:
> On Tue, 28 Jan 2014, Ian Jackson wrote:
>> Q1: Do we intend to support multiple systems long-term, or do we
>> intend to settle on a single system, probably in jessie+1 ?
>>
>> Q2: Is it OK for packages to depend on a specific init syste
On Mon, Jan 27, 2014 at 11:59 AM, Ian Jackson wrote:
>2. Debian intends to support multiple init systems, for the
> foreseeable future, and so long as their respective communities
> and code remain healthy. Nothing outside of an init system's
> implementation may require a sp
On Sat, Jan 25, 2014 at 2:23 PM, Russ Allbery wrote:
> In other words, proposing a ballot here and calling for votes doesn't
> preclude other options. We're all quite capable of saying something if we
> think something has been left off of the ballot, or voting FD. It's less
> formal than the GR
On Sat, Jan 25, 2014 at 2:02 PM, Colin Watson wrote:
> On Sat, Jan 25, 2014 at 01:15:39PM -0500, Michael Gilbert wrote:
>> What about "let the project evolve" it's own solution, and well maybe
>> that is the sysvinit option?
>
> This would amount to &qu
On Sat, Jan 25, 2014 at 1:00 PM, Bdale Garbee wrote:
> I've spent much of the last few days pondering the current state
> of the TC's init system debate, and what our next step(s) should be.
>
> The original question posed to us in bug #727708 was to "vote on and
> decide the default init system fo
On Sun, Jan 19, 2014 at 6:52 AM, Russ Allbery wrote:
> But
> it was way behind both systemd and upstart in terms of readiness in Debian
> going into this discussion, and the amount of catching up that's required
> here for it to displace upstart as my second choice just doesn't seem
> feasible for
On Fri, Jan 17, 2014 at 11:29 AM, Thorsten Glaser wrote:
> Moritz Muehlenhoff dixit:
>
>>FreeBSD upstream isn't a desktop OS and never will be, there're just too
>>many deficiencies (e.g. lack of dbus
>
> Eh, excuse me! It’s obviously possible to run a desktop without dbus!
> In fact, this is a fea
On Wed, Jan 1, 2014 at 3:40 PM, Chris Knadle wrote:
>> I appreciate the explanation, and I'm familiar with the contents of the
>> decision. I simply see nothing there that should have motivated a
>> tech-ctte decision, rather than simply a couple of bug reports against
>> network-manager and an ad
On Mon, Dec 30, 2013 at 10:24 PM, Steve Langasek wrote:
> On Mon, Dec 30, 2013 at 08:12:19PM -0500, Michael Gilbert wrote:
>> > Part of my goal in writing up that plan was, as you
>> > say, to try to provide a means for people who are committed to one system
>> > or
On Mon, Dec 30, 2013 at 7:20 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
>
>>> I believe that we have enough information to make an informed choice
>>> already, and that the sides are fairly well-def
On Mon, Dec 30, 2013 at 7:16 PM, Vincent Bernat wrote:
> ❦ 30 décembre 2013 23:31 CET, Michael Gilbert :
>
>> Doing something like this, the best init system can win based truly on
>> merit (if/when the work gets done), rather than as a fuzzy upfront
>> judgement call.
On Mon, Dec 30, 2013 at 5:51 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Doesn't a TC mandate on the default init system in some sense violate
>> Debian's spirit of meritocracy?
>
> I believe that we have enough information to make an informed choice
On Mon, Dec 30, 2013 at 1:47 PM, Russ Allbery wrote:
>
> 4. Conclusions
>
> I previously argued that much of the benefit of a new init system comes
> from when we can stop maintaining init scripts. I still believe that, but
> after thinking more about the cultural and project issues at stake here,
> 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. But I think these sorts of
> details should be worked out between Matthias and any potential
> co-maintainers he decides to a
On Thu, Sep 27, 2012 at 7:12 PM, Don Armstrong wrote:
> C The committee declines to change the maintainer of the python
> C interpreter packages in Debian.
> C
> C 7. The committee requests that Matthias Klose consider adding
> C additional co-maintainers to the python interpreter package.
I had m
On Wed, Jul 18, 2012 at 12:24 PM, Kurt Roeckx wrote:
> On Wed, Jul 18, 2012 at 10:31:15AM +0200, Stefano Zacchiroli wrote:
>> > The current wording, read literally, means that if I happened to run into
>> > Steve Langasek, say, at a social occasion, I am not permitted to mention
>> > network-manage
On Mon, Jul 16, 2012 at 4:24 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Mon, Jul 16, 2012 at 4:08 PM, Michael Gilbert wrote:
>
>>>> So, really every other aspect of that process is malleable. In this
>>>> case, I it would be incredib
On Mon, Jul 16, 2012 at 4:08 PM, Michael Gilbert wrote:
>> So, really every other aspect of that process is malleable. In this
>> case, I it would be incredibly humble and poignant to initiate a
>> -project discussion prior to the official process since that sets the
>&
> So, really every other aspect of that process is malleable. In this
> case, I it would be incredibly humble and poignant to initiate a
> -project discussion prior to the official process since that sets the
> clock in motion (i.e. someone could get antsy and call for seconds
> before there's rea
On Mon, Jul 16, 2012 at 3:35 PM, Russ Allbery wrote:
>> Since it seems that there is a lot of momentum to push this GR forward,
>> I would like to make a simple request to slow it down a bit. Please
>> initiate the discussion on -project before initiating the GR itself so
>> this can get more visi
On Mon, Jul 16, 2012 at 12:50 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> So, I had though these changes originated from the recent python
>> maintainership conflict, and that was basically confirmed by the bof
>> discussion. The primary motivation for private
On Mon, Jul 9, 2012 at 6:57 PM, Ian Jackson wrote:
> I think the key difference between us is this: you seem to be arguing
> that the wording discouraging or limiting the TC's private
> conversations should be normative - that is, that the text should
> somehow say that under some vaguely specified
On Fri, Jul 13, 2012 at 4:02 AM, Bdale Garbee wrote:
> Russ Allbery writes:
>
>> The question at issue in these bugs is whether it is permissible for
>> a package in main to declare a non-default alternative dependency on
>> a package in non-free. In other words, may a package in main have a
>> d
On Mon, Jul 9, 2012 at 6:57 PM, Ian Jackson wrote:
> Michael Gilbert writes ("Re: Draft GR for permitting private discussion"):
>> Just to clarify, that is not my perspective. Like I said in the
>> following sentence,
>>
>> The importance of a more stri
On Mon, Jul 9, 2012 at 4:55 PM, Christian PERRIER wrote:
> Quoting Michael Gilbert
>
>> > We went back and forth on this in IRC a little bit. The difficulty is
>> > that unless you're going to delegate to some other entity the ability to
>> > decide when the
On Mon, Jul 9, 2012 at 4:57 PM, Don Armstrong wrote:
> On Mon, 09 Jul 2012, Michael Gilbert wrote:
>> Knowledge of that requirement would simply lead to more sanitized
>> subjects lines in most cases. Although those lacking that knowledge
>> may be in for a surprise.
>
>
On Mon, Jul 9, 2012 at 4:35 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> [-Discussion, draft resolutions-]{+Discussion by members of the
>> committee are made public on the Technical Committee public discussion
>> list to the maximum extent possible. T
On Mon, Jul 9, 2012 at 3:45 PM, Ian Jackson wrote:
> Michael Gilbert writes ("Re: Draft GR for permitting private discussion"):
>> I feel like this wording comes across as sacrificing too much in the
>> openness/transparency of the tech committee's discussions.
On Mon, Jul 9, 2012 at 3:49 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I feel like this wording comes across as sacrificing too much in the
>> openness/transparency of the tech committee's discussions. Perhaps
>> something along the following would be
On Sun, Jul 8, 2012 at 11:37 PM, Ian Jackson wrote:
> Russ Allbery writes ("Re: Draft GR for permitting private discussion"):
>> The change to the core of the wording seems fine to me. However, in our
>> previous discussion on IRC, we talked about adding a sentence along the
>> lines of:
>>
>>
I wonder if the core issue at hand here is simply that the python VCSs
are on a resource writable by only one person (meaning no one else can
contribute)? See:
https://code.launchpad.net/~doko/python/pkg2.7-debian
https://code.launchpad.net/~doko/python/pkg3.2-debian
If that's the case, then perh
57 matches
Mail list logo
