On Tue, 24.04.12 21:47, David Strauss (da...@davidstrauss.net) wrote: > Mark Shuttleworth posted recently on Ubuntu sticking with Upstart [1]: > > "Rumours and allegations of a move from Upstart to SystemD are unfounded: > Upstart has a huge battery of tests, the competition has virtually none. > Upstart knows everything it wants to be, the competition wants to be > everything. Quality comes from focus and clarity of purpose, it comes from > careful design and rigorous practices. After a review by the Ubuntu > Foundations team our course is clear: we’re committed to Upstart, it’s the > better choice for a modern init, innit. For our future on cloud and client, > Upstart is crisp, clean and correct. It will be a pleasure to share all the > Upstart-enablement patches we carry with other family friends as soon as > their release is ready and they can take a breath, so to speak." > > I have a few questions I'm hoping people here can help with: > > * How accurate is the claim that Upstart has far more comprehensive > automated testing? If systemd significantly lags here or could -- in any > case -- stand improvement in automated testing, are there any plans in the > works to remedy that?
https://plus.google.com/115547683951727699051/posts/JCDko6rkic5 systemd: 20 test tools, Upstart: 17 test tools. That said, we always can use more tests (and 20 is not much). We could use more tests both integrated in the build system (make check), and outside of it. The thing about an init systems that is different from many other software systems is that you can hardly test them entirely "off-line". To make these tests useful we should actually boot up a full machine and check if that's entirely clean. The ChromeOS folks have an infrastructure that automatically puts together a VM image every time something is commited, then boots it, does some checks that things works, measures a couple of performance parameters (like bootup time) and makes all that available on some web thingy (including graphs showing how boot-up time improve/regress over time). I do believe that this kind of infrastructure would be fantastic to have for systemd too. it probably could be done with a bit of scripting and not too much work with "yum --installroot", genext2fs, and qemu-kvm. (alternatively: debootstrap) Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
