On Wed, Jun 2, 2010 at 10:43 AM, Michael Cronenworth <mike@xxxxxxxxxx> wrote: > Lennart Poettering wrote: > If you can make everyone move away from sysv to something else, then by > all means I'll do my best to aid in patches, but I don't have much > confidence since everything that has been said about systemd has been > said of upstart a few years ago. Instead of reinventing the wheel time > and time again, there are other features that deserve attention. I think its really premature to talk about any situation where we forcibly drop sysv compatibility. Way way premature. It may never be possible in reality. You'll note that so far we haven't actually encouraged the use of upstart native scripts. It's difficult to see how one could lose confidence based on our upstart experience when the reality is we've barely moved away from sysv. We have just a few native upstart scripts. We've essentially been running upstart in sysv compatibility mode putting nearly zero demands on casual packagers to do anything with regard to making init scripts native. That's actually part of the problem with upstart, its lingered for so long in a sort of compatibility mode that its not clear what the realizable benefits actually are. I don't think I've seen any quantitative analysis of the impact of upstart native configs in any real deployment scenario. This is one of the things I'm looking forward to seeing in future systemd discussion. I fully expect that systemd integration to start in a sysv compatibility mode..but with real native configuration usage up front in enough components for us to work with so we can all get a taste of the impact. I fully anticipate systemd sysv compatibility mode as a priority to make sure no casual maintainer is forced to build native configs out of the gate on their own. i fully expect, and trust, that the people who really grok systemd are going to be heavily involved with ensuring the first set of native systemd services are exemplary examples for the rest of us to follow...and to do our best to break. If the wins are obvious, then work on native configs will snowball based on a desire to maximize the achievable benefits. All Lennart is saying is that systemd will have a better experience for packagers while we are navigating the switch-over period. We won't have to play games with subpackages..we ship both sysv and native systemd in the same package. Eventually Fedora project leadership may decide that native configs will be required for new packages or what not as a policy decision...but that discussion is a long long long way off. Let's just see if we can actually get systemd in early into F14 testing, relying on sysv compatibility primarily so we can feel comfortable that its been well tested. -jef -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
