On Mon, 23.08.10 12:40, Matthew Miller (mat...@mattdm.org) wrote: > This seems like a useful behavior, but we can't just make old options have > radically different meaning -- there's really no room for interpretation. > > How about having a new option called "noboot", "nowait", "nobootwait", > "nowaitonboot", "autolater", or somesuch? Although, arguably, if one needs > that kind of functionality, the existing autofs daemon does it in a more > flexibile way already.
Well, it's not really a mount option, it's a systemd option. Anyway, upstream git now makes it configurable globally whether these simple implictly created deps are added or not. It defaults to off. > Is it helpful at this point if I file a bug for systemd's noauto > behavior? Well, given that this is already changed upstream, not really, no. ;-) > This is the second such surprise that I've come across -- "shutdown -r +1" > of course being the other. And of course before that, the long thread about > the chkconfig and service commands. I was positively impressed by your > responsiveness and flexibility on the shutdown delay issue, but I have to > say that the pattern here is making me worried. I don't mean it as a flame > or attack on either you or the project, but I wonder if things are moving > too fast for systemd to be a good choice for Fedora 14. That's quite a jump you are making there. First you say you are happy with the speed I processed your last issue with (and let's also note that this new issue is already fixed, too) and then you say it was too slow on F14. Quite frankly I'd draw a completely different conclusion of the current state of affairs: everything is looking pretty great. The number of bugs open is kinda small, and nothing major of it. And the two issues you raised weren't even bugs, but one was more of a feature request and the other a request of change of behaviour. And anyway, *2* "incidents" don't really make up a pattern, do they? If you'd put the bar for some other package as high as you are putting it for systemd, then well, maybe the Linux kernel isn't ready for F14 yet either? ;-) A little bit more optimism, please! > Again, with no intent to troll, can you estimate how many more changes like > this are in store? Like I hope was illustrated in the "the next steps" > thread, change in itself isn't cost-neutral. When you're replacing a core > component of the OS, and you're faced with a point where a human interface > could be changed, the first thought must be "how can we make this > improvement with minimal disruption?". > > So, my question is serious. If we go ahead with systemd for F14, will we be > hit with an onslaught of confusion, trouble, and change? That would be good > for testing systemd, but *not awesome* for the distribution or for its > users. Or, on the other hand, is it a matter of a few kinks which we can get > solved before release? Well, of course, systemd is magic and bug-free. Because I am Gandhi 2.0 I also have the powers to make everybody happy. Yippieh! Nah, seriously. Every software has bugs. And systemd isn't sysvinit. Because of that it doesn't always behave like sysvinit. But that's expected. I could name you a couple of other things where we depart from sysvinit. (for example, we ignore the Sxx/Kxx priorities of the /etc/rcX.d symlinks by default if the LSB header includes ordering information anyway). Many of these differences shouldn't matter really, and we can often tell people that they are misusing things if they are relying on the old behaviour (i.e. because they apparently didn't use chkconfig in the example mentioned). So, there'll be more stuff coming up, I am sure. I'd bet on it. There will be bugs. I'll bet on that too. But that's fine. That's OK. That's expected. Software has bugs. And first releases of software definitely have bugs. That's why we have all this alpha/beta process for Fedora in place, so that we can find them early. That all said if you have a look on the number and quality of open bugs of systemd for F14 then it appears to be a lot stabler and more polished than probably most of the stuff in the current base system. It's definitely not a good metric, but I do believe if that even if the number increases to a healthy level comparable with other core packages we'd still be fine. So, breath deeply, and let's all be jolly! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
