On Wed, Dec 03, 2014 at 09:11:43AM +0100, Stefano Zacchiroli wrote: > From those who want to drop the CTTE, I'd like to know what would they > have done to decide upon the init system for Jessie.
There were two aspects to that question: do we support non-default init systems, and which is the default init system [0]. At the time it was brought up the ctte, both systemd and upstart proponents were, AIUI, arguing for one init to rule them all [1], [2]. [0] http://lwn.net/Articles/572805/ [1] https://lists.debian.org/debian-ctte/2013/10/msg00046.html [2] https://lists.debian.org/debian-ctte/2013/10/msg00042.html If I were BDFL, I'd have said "we support multiple init systems", asked the release team to decide to what extent (if any) a lack of support for particular inits should be treated as RC, asked the ctte to provide technical advice on the benefits and drawbacks of each init system, and had a GR (or a less formal poll of developers, contributors and/or users) to choose which was the default. I think the ctte's technical review of upstart and systemd was valuable (and not a one-off), so I don't want to drop it. I also think there's merit in the idea that having a small group make the decision on which is default so that the project as whole doesn't have to devote time and attention to it; but if it's going to be a huge controversy that everyone pays attention to anyway, I'd (personally) prefer a broad base of less-informed voters than a small group of potentially biassed experts. > It seems to me that > we have tried not to use the CTTE on that dispute for several years, > with the net result of raging flamewars and no decision. I think the most important decision that should have been made earlier was going from supporting a single init system to providing a default and supporting alternatives. > The only alternative to a CTTE seems to be using GRs to settle otherwise > non-settlable disputes. All disputes are settlable as a matter of technical fact, for instance: - the default init system is whichever is included in base, which is controlled via Essential:yes flags, Priority: fields from the overrides file, dependencies, and debootstrap - if there's only one supported init system, changing it means moving the Essential:yes flag from one package to another (sysvinit to systemd, eg) - if there's multiple supported init systems, changing the default means changing the overrides to upgrade one to required and downgrade the other top optional, and/or changing the order of dependencies is the Essential:yes package that depends on the actual init systems ("init") - if two conflicting packages try setting Essential:yes, ftpmaster can resolve that by dropping one package or the other, and requiring it to go through NEW on the next upload; if two conflicting packages ask to both be Priority:required, ftpmaster chooses which one wins when setting the overrides - if the ordering of dependencies matters, the maintainer of the package gets to choose who wins as part of the next upload -- init is maintained by the systemd packaging team. alternatively someone hijacks the package, or there's an upload/counter-upload war, and ftpmaster can choose a winner by blocking the other party's uploads. That line of reasoning mostly ends up with disputes getting ultimately settled by ftpmaster and the release team (for the distro contents), debbugs admins (for "this is a bug, not it's not" complaints), and potentially DSA (for what's a Debian service) and DAM (for who speaks for "Debian"). Conflict resolution by cabal, ultimately. Cheers, aj -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203100834.ga23...@master.debian.org
