Announcement

Collapse
No announcement yet.

Voting Proposed For Debian Jessie's Init System

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by interested View Post
    Don Armstrong has just voted sysvinit as the primary init system (5 4 3 2 1), again putting systemd last...
    That's not how I read it. He voted 5 (FD), all other choices being equal pending further discussion.
    https://lists.debian.org/debian-ctte.../msg00462.html
    Last edited by eidolon; 01-27-2014, 05:26 PM.

    Comment


    • Originally posted by GreatEmerald View Post

      And as far as I can tell, most people in the TC feel that staying with sysvinit is the worst thing that could happen. [snip]
      Nevertheless two CTTE members have now ranked sysvinit as their main choice suggesting some sort of collusion and extreme tactical voting, and I therefore suggest even the Upstart maintainer will rank sysvinit higher than Upstart.

      Having sysvinit as default initsystem for Debian Linux is of course really, really bad for Debian. But it may be a clear benefit for Canonical, in that this will almost force Debian to support multiple init systems because the default is so bad. That way Upstart is likely to be mandatory supported by Debian maintainers as a secondary initsystem, a clear boon for Canonical.

      Comment


      • Originally posted by prodigy_ View Post
        Not to mention they break UNIX principles at whim and seem to be proud of that.
        you realize that Debian is Linux =! Unix ...
        thank god
        all those principles ... in germany we say "prinzipipenreiter" to people who say that they want something just because the principle exists. The good thing for those people is, that they donīt have to think if the principle makes sense in a given situation...

        Comment


        • Originally posted by eidolon View Post
          Regardless of how the TC votes, I think it is likely that there will be a GR on the issue (particularly since the TC has agreed in principle to allow for a simple majority to overrule the vote), because there isn't a single choice that will sit well with all Debian developers. If it would keep the TC from going into full-on meltdown mode, perhaps Debian should just skip straight to a GR (despite arguments against doing this in the first place). At least the whining can be marginalized once a GR has passed, and hopefully the bulk of the bad blood, misrepresentations, and FUD will have been exhausted by then. It really doesn't need to be this melodramatic.
          Yea, given that the TC is largely deadlocked, a GR will be needed in any case, and if they allow a majority overrule, then there is little point in the vote...

          On mass votes for technical decisions, I always feel that some sort of balancing is needed (be it this case or referendums in general). There are people who have really studied the topic a whole lot, and then there are impressionable people who vote just for the heck of it or out of ignorance. It doesn't seem fair that their votes count equally... If people were forced to read through pros and cons of each option before being allowed to vote, that would ward off most of the latter. Or allow everyone to vote, but give more weight to people who read through the text (perhaps have a mini questionnaire from the text to make sure the person has really read it, and not just pressed the "next" button; the score could determine the weight). Without that, due to human nature, there might be way too many votes for sysvinit, because people are resistant to change and are unaware of its shortcomings.

          Originally posted by interested View Post
          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.
          From what I understand, he voted 5 and nothing else (he put equal marks between the others, so probably 2.5 points for each if the vote ends up counting; it could have been stated as 5 1=2=3=4 just as well, but it doesn't look as good a sequence).

          Comment


          • Originally posted by eidolon View Post
            That's not how I read it. He voted 5 (FD), all other choices being equal pending further discussion.
            https://lists.debian.org/debian-ctte.../msg00462.html
            I should have said, that he ranked sysvinit as his primary initsystem, which he did, even though FD was the first item of the list. Remember Debian CTTE uses a variant of the Condorcet voting system. A strong number two may win over a split number one, and by ranking them equal value, all options becomes "number two" option as I understand it. So it may not be carelessness that have made them both put sysvinit in as option number two.

            Se more info here.
            http://www.seehuhn.de/pages/vote

            Comment


            • Originally posted by interested View Post
              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.
              Not properly, the Don's vote is:
              5 (4=3=2=1)
              note the equal operator between the other choices.
              It looks like will be a "further discussion"... until the end of the world, probably.
              The TC works on this bug from the start of October and now, at the end of Jannary, we just have a "further discussion" non-solution.
              Two words about the eventually GR:
              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?
              If the TC stops to take decision because the GR could override it, then what is the TC's purpose?
              Just call a GR from the day one.
              Last edited by valeriodean; 01-27-2014, 05:48 PM. Reason: typo

              Comment


              • Originally posted by interested View Post
                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).

                Originally posted by GreatEmerald View Post
                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".

                Comment


                • Originally posted by valeriodean View Post
                  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.../msg00464.html

                  Originally posted by mrugiero View Post
                  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.

                  Comment


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

                    Comment


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

                      Originally posted by liam View Post
                      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.

                      Comment


                      • Originally posted by eidolon View Post
                        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).

                        Comment


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

                          Comment


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

                            Comment


                            • Originally posted by GreatEmerald View Post
                              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.../msg00464.html
                              Agree, infact the presence of too much Upstart's dev/maintainers into the TC has disturbed me from the first minute.

                              Comment


                              • So what is the actual result of the vote ?

                                Comment

                                Working...
                                X