Voting Proposed For Debian Jessie's Init System

[mrugiero]

Yeah, unless we're talking about Wayland, apparently.

No, it's exactly the same when talking about Wayland. The thing is, that list of options never says you won't get judged or disagreed upon. Free software is, after all, derivative of free speech.

[GreatEmerald]

Well, the Debian mailing list now reminds me of scenes from Phoenix Wright... Objections aplenty. And someone wrote a summary of things that were less than stellar during the whole process: https://lists.debian.org/debian-ctte.../msg00476.html

[valeriodean]

Yeah, unless we're talking about Wayland, apparently.

Not apparently, but for a good reason: the graphic card's manufacturer.
There are no problems for the open drivers except the work to do, but if the user want/need to have the best from his hardware, then the manufacturer's drivers must be avaiable for that display server.
In the case of the display server, the work to do is not on the hand of free/open developers only, so you cannot fill the gap only thanks to the volunteers' work.
So yeah, to me If we are talking about display server the things are different.

P.s.
Different scenario happens if both the new display servers can be sodisfied through the same interface (i.e. EGL).

[GreatEmerald]

So what is the actual result of the vote ?

Further Discussion. The new voting ballot is being prepared right now: https://lists.debian.org/debian-ctte.../msg00486.html

[doom_Oo7]

So what is the actual result of the vote ?

[valeriodean]

I'm inclined to agree. but then I'm also quite a bit torn here. The thing is, I'm not really satisfied with what the TC has, either, as the arguments given by the Upstart camp really sound poor to me (especially Ian Jackson's points). Given that so many members of the TC are involved in the making of Upstart, I'm inclined to believe that the GR would result in a less biased vote. On the other hand, the GR is for Debian developers, which basically means the guys maintaining init scripts. On one hand, that's good, because it means they are more familiar with the question at hand (as opposed to regular users). On the other hand, it's not good because they had to maintain sysvinit scripts until now. Choosing sysvinit is the no-op way out: they don't have to do anything for the next release, since everything is already working right now (well, unless you're a GNOME Debian developer). Such an option is mightily convenient. The ones that get hit bad by this option, though, is system administrators (who don't get to vote).

So bad options all around. TC would be biased towards Upstart and GR would be biased towards sysvinit.

By the way, interesting twist related to this and what I said in my last post: Keith Packard pretty much echoed the thoughts and believes that in the GR people should be asked to investigate the issue before voting (and also he wonders whether putting things on the GR without a TC decision means the TC is lazy and incompetent):

https://lists.debian.org/debian-ctte/2014/01/msg00464.html

Agree, infact the presence of too much Upstart's dev/maintainers into the TC has disturbed me from the first minute.

[GreatEmerald]

Same with Andreas Barth, which most likely means that after it's cleared up his vote will be 21345. Also, the current vote means that voting is terminated until a new proposal is made.

[Scimmia]

Steve Langasek has now also voted, 52134.

I'm glad that he didn't buy into any of the politicizing, this seems like an honest technical vote to me.

[liam]

OT: I see little to suggest Fedora.next isn't potentially a can of worms itself. I'm not saying it's an inherently bad initiative, but implementation will make or break most people's long-term opinions of it.

I wouldn't call it a can of worms. For the most part those who are simply against it aren't either major contributors or contributors at all. Now they are certainly part of the community so they are getting a say but it looks like it's currently more about details than if amongst the decision makers.
I think almost everyone is going to be very happy with the "introduction" of ring 0 (they've dropped that nomenclature but I don't recall the new name). QA's job should become easier if only because of more clearly defined objectives for each layer and the expectation of a Docker-like solution for third party software (at least on the server/cloud).

[eidolon]

OT: File under: http://www.phoronix.com/forums/showthread.php?t=94628

All to the good for fedora.Next.

OT: I see little to suggest Fedora.next isn't potentially a can of worms itself. I'm not saying it's an inherently bad initiative, but implementation will make or break most people's long-term opinions of it.