Re: draft alternative proposal: fix problem at the root
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
Reply to: