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
> no others.
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
notes.
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 future releases.
> > - 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@xxxxxxxxxx>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
