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