Voting Proposed For Debian Jessie's Init System

[mrugiero]

But that means that not only is his vote political (for the Ubuntu cause, not Debian), he is also insincere in his voting. He is on a technical committee, elected to vote on technical issues. If he disagree with the voting agenda, he should argue with his colleagues, not abusing the voting system by making insincere votes.

Not really. He acknowledges the one proposing the voting was technically in his right, so he must play along with it. He still disagrees on that decision, adn states it. Also, you still haven't proved he isn't voting in a technical basis.

His strategy seems now to be make sysvinit the default init system in Linux, a solutions so technically bad, that it will be easy to persuade people afterwards, that multiple init system is mandatory for the Debian maintainers to maintain, among these Upstart. That way he can make Debian work towards Canonical goals.

Do you realize the voting is for the next release only? Also, multiple init systems will be needed for Debian to maintain if systemd wins, as they don't nor they can support the other kernels Debian uses.

Don Armstrong has just voted sysvinit as the primary init system (5 4 3 2 1), again putting systemd last, so they seem to have communicated beforehand.

Or he just feels that way. I'd vote the same, although my second option would be systemd instead of the last. Why? Because I think they should stick to sysvinit for the next release, except if they actually agree this decision will be final and won't change for the next one. If they are so stubborn in changing without being sure they won't want yet another change for the long-term, then I'd prefer systemd, because that's what I want them to pick as a final decision. I'm assuming they will do multiple in the end, and the choice will always be just the default, although I expect this to be just sysvinit plus a new one, or anything compatible with their other kernels plus one suited for Linux (preferably systemd).

I didn't say he said he voted against systemd for political reasons specifically; I said he said his vote was for political reasons, and it is. He emphasised the voting rules, yes, but he didn't explicitly state that he didn't vote the last place for systemd for political reasons, either. If the first part of the vote is political, he might as well have made the rest political as well (putting systemd at the last place does make it more likely to get sysvinit AKA status quo).

And I never said it was impossible that he voted on political reasons, either. I said there aren't enough proof of that to say so that sure. I don't pay too much attention to who writes what, so maybe it wasn't you, but I recall at least two posts firmly asserting his vote against systemd was based on political reasons.

And as far as I can tell, most people in the TC feel that staying with sysvinit is the worst thing that could happen. It's inadequate, and the later they start moving, the longer the transition period will go, and the longer people will have to suffer with init scripts. So delaying a decision and hoping it defaults to sysvinit staying reminds me of the US financial situation ? both sides can't agree with each other, and thus the outcome is what both sides wanted the least. And that's just bad for everyone involved.

I agree with you, partly. My point is, they are deciding for the next release. If this argument will start again for the next one, there is a noticeable chance they will have to undo all the work they do for this release, and yet probably add some extra work on top, and that would be just pointless. I hope they agree that this decision will be final before deciding on change, it's just that. If they do agree on that, then I agree the worst they can do is stick to sysvinit. If they don't, they should stick to it, because it's the one involving the least waste of time in migration and re-migration.

About the finality of the decision, well, from what I gathered, most TC members have already decided and I don't see anything changing their decisions. So delaying the vote is rather pointless, as they already investigated the options well enough; it's not rushing, because this question has been raised a while ago. Plus this decision can be overruled in any case. But it will be a basis they can finally agree on, and thus move on to more productive things, like planning the actual transition.

Maybe it is, but it doesn't seem like it to me. All I gathered is "we have no idea what we'll be doing in the next release, and we aren't thinking long term".

[GreatEmerald]

the TC has spent a lot of time to investigate about the capability, the weakness and the strongness of all the available init system (more or less, I have some doubts about one or two member), the other devs involved in the hypothetical future GR, will do the same? Will they spend the same ammount of time to reach a proper informed decision?

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

I agree with you, partly. My point is, they are deciding for the next release. If this argument will start again for the next one, there is a noticeable chance they will have to undo all the work they do for this release, and yet probably add some extra work on top, and that would be just pointless. I hope they agree that this decision will be final before deciding on change, it's just that. If they do agree on that, then I agree the worst they can do is stick to sysvinit. If they don't, they should stick to it, because it's the one involving the least waste of time in migration and re-migration.

I'm kind of torn here as well. Yes, it would be most unfortunate if they had to switch two init systems in the space of two releases. But by the time they do the second release, new things might develop that changes the situation, and thus a remigration would be required. So I don't think it should be strictly a final decision. Besides, once something is picked, even if it's not stated it's final, it will probably stay final, because people will recognise that there was effort put into the migration and voting against that means trashing the efforts (plus people don't like change, anyway). That is, unless there is really enough reason to justify it. Also, I'm also pretty sure sysvinit is automatically a non-final option and the same question will probably be raised on every release until someone votes for something other than it.

[liam]

All to the good for fedora.Next. Debian got a big infusion of users after the fedora core migration so maybe Debian being stagnant and increasingly removed from the direction Linux is moving will bring those users back.
Fedora could certainly use a large influx of non-Gnome people.

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

[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).

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

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

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

[doom_Oo7]

So what is the actual result of the vote ?

[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