So it appears that the Debian ctte discussions are now stuck at a 4:4 stalemate between systemd and Upstart.
What I find interesting about this, is that during the discussions some of the most fundamental questions were never asked: do the three contenders actually do what one would expect from a modern system that brings up the system and manages services? Are they substantially better than what sysvinit provided?
When looking at the boot process of modern computers, there are some bits that are certainly more important than others. One of the most important ones is getting the logic right how file systems are set up: the system needs to wait until all block devices from /etc/fstab have shown up, have been fsck'ed and have been mounted. Only after this has been done for all file systems listed boot may proceed.
On sysvinit this crucial part of the boot process was very poorly implemented: there was simply no scheme in place to wait for the devices from /etc/fstab to show up. Instead, through a mix of sleeping + "udev settle" + scsi_wait_scan the system would wait for a point in in time where "all" devices have shown up, then it would fsck them all, and then it would mount them all. This scheme worked fine on 90's hardware, since all hard disks were local and storage systems simple: it would be unlikely that devices would not have been found and probed within that magic sleeping interval. However, this is really not how modern computers work. Nowadays pretty much all hardware is hotplug capable, and for most hardware there is no time guarantee whithin which all connected devices have to have shown up (and this can get quite bad, for example on USB or iSCSI, or RAID stuff). Thus, any scheme that doesn't take into account which the devices are that need to be waited for, is simply unreliable and slow (since one doesn't know how long to wait, one has to wait for longer than really necessary). Reliability is crucial for server setups, and boot times for client machines. sysvinit is good at neither.
Now, when we look at the three contenders, we notice that one of them brings exactly nothing to the table here that is any better than sysvinit here: OpenRC does not understand /etc/fstab, it has no facility to wait for the devices listed in them, fsck them, mount them.
Upstart is much better here: it contains a binary called "mountall" that will wait for the devices in /etc/fstab to show up, will fsck them and mount them. So on the first peek everything is fine, it should be sufficient to just call this at boot and all is good, right? Well, in a way that's true, however I think the existance of this tool exemplifies, illustrates like little else how insufficient and broken the basic Upstart design actually is: even though Upstart is "event-based" and all, the most crucial, relevant part of the boot process it cannot cover: the waiting/fscking/mounting takes place completely outside of Upstart's rules engine. The Upstart developers resorted to a completely external state machine for the most important part because they coudln't map it to Upstart's design. But what good is the design if it cannot even cover this central part of the boot process?
(I figure I don't have to mention this: systemd OTOH will parse /etc/fstab, and integrates its contents neatly into the dependency tree as little more than just another source of configuration.)
The existance of mountall on Upstart, and the non-integration of /etc/fstab into the Upstart rule set, results in a lot of additional shortcomings: mountall is a one-time thing for the boot process, all context of file systems, devices and mounts is lost, after it ran, and the file system state is henceforth assumed static. Which of course is not how systems work these days...
This design flaw is one of the things we noticed when we looked into Upstart in detail before we decided to start systemd. 4 years later, nothing has changed, the Upstart design still cannot cover this...
And there are more low-level questions like this one should ask, that should appear as absolute baseline what to expect from an init system. For example:
a) Does the init system support auto-respawning of services on failure/coredump/..?
b) Does the init system record exit status/signals/coredumps of services for later retrieval by the admin?
c) Does the init system record stdout/stderr of all system services for later retrieval by the admin?
d) Does the init system support timing out all service operations such as start or stop?
e) Does the init system support rate-limiting all service operations such as start/.. ?
f) Does the init system support basic resource management operations for services, for example, limiting CPU usage, memory usag, IO usage of a service, and so on?
And so on... Of course, systemd will cover all of the above fine, since we wrote it specifically with an enterprise usecase in mind, which needs to cover all of this. Note that the the points raised above are hardly something of the fancier features of systemd, they are really just the absolute baseline a service manager should cover. OpenRC falls short on most of these, Upstart faires considerably better, but it certainly doesn't cover it all...