On Tue, Aug 24, 2010 at 08:45:33AM -0400, Matthias Clasen wrote:
> GENERAL SANITY
> - Booting a system shall achieve a similar result as booting in upstart:
> -- The same set of services will be started.
I don't think this is a requirement on systemd, really. If we make
changes to the default system configuration to not include a service in
F14 that was included in F13, that is not a systemd problem. So, I think
what you really mean here is: systemd will start all services that are
configured to be included in the default install (and dependencies), but
If we're still including upstart as a fallback option, I think it's
reasonable to ask that making that selection doesn't significantly change
what gets started -- *or*, that if it is expected to behave differently, all
ways in which it will be different are clearly documented in the release
Cases where I think documenting differences is appropriate rather than
requiring identical behavior would be:
- services which take advantage of fancy new systemd features
- services which take advantage of any upstartd features which systemd
does not implement in a similar fashion (if such things exist).
- services where the end-user has gone out of their way to configure
upstart in a fancy non-default way.
It'd be *nice* if the last case could automatically work too, but I'm not
expecting magic. So instead, we need to be clear.
> - The basic syntax of systemd commands shall be frozen for
> - The syntax of systemd units shall be frozen for future releases.
Again, the best we can ask for is backwards compatibility, I think.
'Frozen' is entirely too strong for a 2 month old project.
In fact, I think we need some flexibility to change things which turn out to
be sub-optimal once they're out in the real world. Freezing these decisions
too soon is one of the strong arguments for waiting until F15.
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences