Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, November 6, 2013 09:10, Russ Allbery wrote:
> "Thijs Kinkhorst" <thijs@debian.org> writes:
>> On Wed, November 6, 2013 01:16, Russ Allbery wrote:
>
>>> We'll want to look at both sides of that question, and try to
>>> understand how much work like that is potentially on the horizon with
>>> the various choices.
>
>> Do you? In the past Debian has not shied away from making the choice
>> that it considers technically (or philosophically) the most sound, not
>> the one that implies the least amount of work. The choice will probably
>> be made on just a few high-level factors, such as the chosen approach
>> (dependency vs event based), best user experience and/or licensing.
>
> Well, my choice won't be made on just those few high-level factors, for
> whatever that matters. And I seem to have one. :)
>
> Technically the most sound and implying the least amount of work are not
> two unrelated factors. Apply reductio ad absurdum: vaporware is not
> technicallly sound, regardless of what lofty design principles underlie
> it.
>
> We need to be realistic here about what we, as a project, can accomplish.
> The ideal init system for Debian is, almost by definition, the one we
> write ourselves from scratch to do exactly what we want it to do. There's
> a good reason why no one has proposed that. We have certain realistic
> limitations about what we can and can't do as a project, which in this
> space, among other things, require us to adopt an existing project rather
> than writing our ideal implementation from scratch.
I doubt that Debian writing something from scratch would not be realistic:
Debian actually has chosen to go the self-implementing route in key
infrastructures the past, for example for the installer or package
managers.
Nonetheless, that's not relevant here. There are several likely candidates
in existence, so the choice will not be to use something existing versus
implementing from scratch; the choice will be between existing projects,
and given that, the amount of work per system may differ but the
difference will not likely be that great that it's unsurmountable, as they
exist, they have active upstreams and they have successfully been used in
other distributions.
> That metric is trying to get at something that we do care about, namely is
> a particular upstream project going to be excessively buggy (poorly
> documented code implies harder to understand code implies people make
> mistakes when they change it) and can we understand it well enough to make
> whatever integration changes we need to make to it.
I do agree that it's nice to have the very best code quality available,
but in the long run, having underdocumented code is annoying and may lead
to bugs, but bugs can be fixed and documentation improved; changing the
basic architecture of the system is unlikely to be fixed. I really believe
we are going to regret it if Debian chooses the architecture it likes less
for the reason that it has more documentation.
Which system has better code documentation is not relevant. The relevant
question is whether a system has adequate documentation, regardless of the
documentation of other systems.
I think I would like it better if the choice process was split in two.
First, for each candidate system assess the supportability in Debian. Code
quality can be a factor here. Can we reasonably run this? (Given that the
two major choices have been used by several other distributions probably
qualifies them, but Debian can make its own assessment here.) Then, from
the shortlist of candidates, choose the 'best' one based on high-level but
fundamental criteria, like architecture, licensing etc.
Currently, it seems these two steps (is it supportable vs what should be
the default) are conflated and a big matrix of facts of the different
systems is built.
Cheers,
Thijs
Reply to: