"Thijs Kinkhorst" <th...@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. The same also applies to other subsystems that go into our distribution. We aren't going to, realistically, write our own new syslog implementation, or our own new user session manager, or our own udev implementation, or our own desktop environment, or our own kernel. We're going to use existing projects, maintained by other people with other goals, some with goals that have nothing to do with Debian's goals. We need to choose useful, interoperable sets of those projects that can, at the end of the day, come together into a coherent system for our users. Since that's why we're all here. As part of that process, we may well contribute to those projects, perhaps substantially. But Debian is not an island to itself, and if we pretend we are, we won't produce the quality of distribution that we want to produce. We're part of a larger ecosystem, and that has quite a bit to do with the specific decision of how we choose our init system. > Facts are being gathered about the percentage of code comments, but I it > seems unlikely that Debian would reject a solution that it thinks is > architecturally superior because of it having fewer code comments. 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. Percentage of code comments is a very rough and somewhat dubious metric to use for getting at that question, but it's getting at something real. Just like the discussion that we had about syntax is getting at something real around the UI of the init system that we will expose to our users, even if the specific question of how one embeds shell commands in the startup script is not one on which the choice of init system will turn. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
