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
Debian, and resolves this particular
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 we should
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, to a
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 specified
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 new
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
for
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
consensus, so Ian's objections to all
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 don'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 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,
Mike
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 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 resolution
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 your
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
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
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.
Shouldn't the TC members focus on their own
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 conditions for another cycle.
Which have
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
system.
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
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 would not
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 system as
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 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, being allowed to “do what it
wants
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
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 for
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 further discussion, so I believe it's adequately
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 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 me.
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 feature, in
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 added
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 the other to continue to work on what
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,
as
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.
Unfortunately, being the best
On Mon, Dec 30, 2013 at 7:20 PM, Russ Allbery wrote:
Michael Gilbert mgilb...@debian.org 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-defined and hardened
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
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 add
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-manager and
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 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 discussion stated
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 visibility
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 really
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
clock in motion (i.e. someone
On Mon, Jul 16, 2012 at 4:24 PM, Russ Allbery r...@debian.org wrote:
Michael Gilbert mgilb...@debian.org 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 incredibly humble and poignant
On Fri, Jul 13, 2012 at 4:02 AM, Bdale Garbee wrote:
Russ Allbery r...@debian.org 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
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 stringent wording (I think) is to make it clear
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.
If the subject lines were sanitized
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 TC can hold private discussions (which I don't
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
48 matches
Mail list logo
