| |||||||||||||
|
| |||||||||||||
Systemd and Fedora 14Systemd and Fedora 14Posted Aug 26, 2010 10:41 UTC (Thu) by mpr22 (subscriber, #60784)In reply to: Systemd and Fedora 14 by marcH Parent article: Systemd and Fedora 14
I have one intuition about those numbers (for the record: "not many" and "probably even fewer"). You may well have another.
(Log in to post comments)
Systemd and Fedora 14 Posted Aug 26, 2010 13:45 UTC (Thu) by marcH (subscriber, #57642) [Link]
> How many people who wouldn't try out a prerelease distro to test an experimental system initialization manager would choose the option to use the optional experimental system initialization manager in a released distro [...] ?
Comparing the times respectively required will guide you towards the answer.
> How many of those people would, having found the optional experimental system initialization manager to be buggy in Release N, try it out again in Release N+1?
They would try it again simply because in N+1 it would have become the default. I am not suggesting to drag things forever either; it's all about finding the right balance.
Systemd and Fedora 14 Posted Aug 26, 2010 15:13 UTC (Thu) by vonbrand (subscriber, #4458) [Link] If it is shipped experimental and broken in N, it won't be the default in N + 1. It might even not be in N + 1 at all. End of story. BTW, there are experimental packages of systemd at least for OpenSUSE out, and some other distributions are considering it. To test it, it has to go out to users (sure, at first just die-hard masochists, but soon after you need to reach out to the others). Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time. And that is bad for developer morale (and focus), and probably damages the whole effort.
Systemd and Fedora 14 Posted Aug 26, 2010 20:04 UTC (Thu) by marcH (subscriber, #57642) [Link]
> If it is shipped experimental and broken in N, it won't be the default in N + 1.
Sorry but I totally miss the logic here.
And the solution to such a sample (and irrelevant?) situation would be to fast-track this supposedly broken piece of software? In other words, to burn the bridges?
> And that is bad for developer morale (and focus), and probably damages the whole effort.
Yes this is all about the balance between the vast majority of Fedora users, happy with a system that already works fine thank you very much, versus a few admittedly brilliant developers overexcited about a new fancy project.
Systemd and Fedora 14 Posted Aug 26, 2010 21:03 UTC (Thu) by vonbrand (subscriber, #4458) [Link] This is not "already works fine, thank you" but "works so-so with massive effort and tweaking, and won't survive the next round of hardware/software updates". Fedora isn't running SysVinit anymore, and upstart is clearly lacking (it is being used only as a SysVinit replacement). A rethink of the whole mess is mandatory (not least because you can't separate system vs user setup anymore for increasingly broader end user control over the machine). This is a concrete proposal to do so, and it mostly works today (with surprisinly little futzing around in daemons), and which has been greeted with enthusiasm by other distros (best example is that it is being considered by them, and experimental packages exist). Will it hurt? Yes. Will it be worth it? I believe so.
Systemd and Fedora 14 Posted Aug 28, 2010 0:12 UTC (Sat) by Blaisorblade (guest, #25465) [Link]
> To test it, it has to go out to users (sure, at first just die-hard masochists, but soon after you need to reach out to the others).
Hey, it's cool, but until the bug stream doesn't slow down, there's no chance that you can include it in a distribution. Not even in one as crappy as Fedora. We've suffered this style ever since RH 9's (IIRC) backport of NPTL.
> Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time.
Yes, at some point there won't be new bugs reported. Then it means you can end the beta-test phase, set up more stress-testing, get more packages to work with it, ship it, and fix the tons of bugs reports.
> And that is bad for developer morale (and focus), and probably damages the whole effort.
Hey, that's crap. If developers can't wait six months to replace the core component of a system, they should be fired. Now. Because they wouldn't be able to deal with much harder problems. I guess it does not matter, because it's just your idea.
Finally, reading one of the original Nottingham's comments linked from the article [2] is enlightening. He's teaching release management to Poettering. Which means that I don't trust him to care for a distribution. Sure, he's a great and brilliant developer, able to think different, but those guys are not good for ensuring stability.
[1] http://lwn.net/Articles/401901/
Systemd and Fedora 14 Posted Sep 2, 2010 8:29 UTC (Thu) by renox (subscriber, #23785) [Link]
>> Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time.
> That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.
Depends on the distribution!
"Leading the advancement of [cut] software" are nice "marketing" word for "bleeding edge", what is right for a distribution aimed at "non-technical users" or enterprise isn't necessarily right for a "bleeding edge" distribution..
Note that I'm not saying this as a criticism against Fedora, we need "bleeding edge" distributions to make rapid progress, and I applaud them to take (calculated) risks.
|
|
||||||||||||