I have skimmed through the debian-devel threads regarding systemd a bit. I didn't read all of it, it's just too much and highly repetitive. But here are a few points I'd like to make, for those who care:

Whether Debian chooses systemd or Upstart has major implications on the future too, so you shouldn't only look at what is now, but also keep in mind what will come next. And there are at least two areas where opting for Upstart will mean you shut out Debian of major changes.

One is the cgroup situation. The kernel folks want userspace to have a single arbitrator component for cgroups, and on systemd systems that is now systemd, and you cannot isolate this bit out of systemd. The Upstart world has exactly nothing in this area, not even concreter plans. There are dreams of having some secondary daemon taking the cgroup arbitration role, but that's a complex task and is nothing you can just do at the side. I am pretty sure the Ubuntu guys don't even remotely understand the complexities of this. Control groups of course are at the center of what a modern server needs to do. Resource management of services is one of the major parts (if not the biggest) of service management, and if you want to stay relevant on the server you must have something in this area. The control group stuff exposes an API. The API systemd exposes is very systemd-specific, it is unlikely that whatever solution Upstart one day might come up with will be compatible to that. Of course, at that time a major part of the Linux ecosystem will already use the systemd APIs...

The other thing is kdbus. The userspace of kdbus pretty much lives inside of systemd. Bus activation work will be using the same mechanisms as socket activation in systemd, and again you cannot isolate this bit out of systemd. Basically the D-Bus daemon has been subsumed by systemd itself (and the kernel), and the logic cannot be reproduced without it. In fact, the logic even spills into the various daemons as they will start shipping systemd .busname and .service unit files rather than the old bus activation files if they want to be bus activatable. Then, one of the most complex bits of the whole thing, which is the remarshalling service that translates old dbus1 messages to kdbus GVariant marshalling and back is a systemd socket service, so no chance to rip this out of systemd.

So yeah, these things are already part of systemd, and I believe that both are highly relevant on what people want from a Linux-based operating system. If you go for Upstart then you opt out of this. I have serious doubts that Canonical will play catch-up with this so quickly. The last time they tried that they took logind out of the systemd tree and ported it to Upstart. logind of course is one of the components of systemd where we explicitly documented that it is not a component you can rip out of systemd. And of course, just a few months after Canonical did this, things are broken again, and this was to be expected: logind now uses the new cgroups userspace APIs (as mentioned above), and hence it will not run without systemd around. So Ubuntu is stuck with an old and unsupported version of logind. If they advocate this as a solution, then they are in ignorance onthat what they have is already out-of-date. (And yeah, this matters, for example all the nifty stuff that allows Wayland to run nicely without privs is implemented in the newer logind versions, and not in Canonical's forked version).

I believe ultimately this really boils down to this: the Linux userspace plumbing layer is nowadays developed to a big part in the systemd source tree. Ignoring this means you constantly have to work with half-baked systems, where you combine outdated components which do not belong to together into something that in many facets might work but is hardly integrated or consistent. Or to put this another way: you are at a road fork: either you take the path where you use the stuff that the folks doing most of the Linux  core OS development work on (regardless if they work at Red Hat, Intel, Suse, Samsung or wherever else) or you use the stuff Canonical is working on (which in case it isn't obvious is well... "limited").

People on the email thread have claimed we had an agenda. That's actually certainly true, everybody has one. Ours is to create a good, somewhat unified, integrated operating system. And that's pretty much all that is to our agenda. What is not on our agenda though is "destroying UNIX", "land grabbing", or "lock-in". Note that logind, kdbus or the cgroup stuff is new technology, we didn't break anything by simply writing it. Hence we are not regressing, we are just adding new components that we believe are highly interesting to people (and they apparently are, because people are making use of it now). For us having a simple design and a simple code base is a lot more important than trying to accommodate for distros that want to combine everything with everything else.  I understand that that is what matters to many Debian people, but it's admittedly not a priority for us.

Canonical over the years has been working hard on building its own stack that is different to what others do to a major degree. Whether it is Upstart, Mir or Unity, there's a line through the whole stack where they make other choices. Every one of them is pretty much a Canonical exclusivity right now. It's up to Debian to decide whether to follow that, or whether the other communities aren't the happier places to be in.

I used to be a Debian contributor a long time ago (I maintained one package but never became a real DD), I care enough about Debian to attend DebConf this year. However, it is of course Debian's decision which path to go. I just hope you guys do it knowing what's at stake here. The least I'd like to ask the technical committee is to thoroughly do your research, and decide on the technology, and the future prospect, not philosophy and not which company you belong to. And yeah, we, upstream, are of course open to answer any questions you might have. And make sure to actually try the two candidates out. Play around with systemctl, with journalctl, and suchlike. To make an informed decision you must have played around with the actual code, it is not sufficient to just comment from the sidelines.

I understand that at least two votes on the technical committee are by people who play a major role in the development of Ubuntu. Both of them are to a large degree responsible for the strategy that Canonical has on on the development of their core OS. It is highly unlikely that they will vote against Upstart when it comes to it (I mean, how would they explain this to their space boss?). So yeah, I figure that Upstart's cards in this game are much better (maybe marked?) than systemd's, but hey, I'd at least like to to be able to say one day that I tried ;-).

Debian, please make sure you know what you do. Be aware that above anything else you make a decision for the future (not the present, not the past), and figure out what that future should be like for you.

And that's all I have to say. Happy decision making!