2010/8/24 Lennart Poettering <mzerqung@xxxxxxxxxxx>: > On Tue, 24.08.10 12:56, Mike McGrath (mmcgrath@xxxxxxxxxx) wrote: > >> >> On Tue, 24 Aug 2010, Adam Williamson wrote: >> >> > On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote: >> > >> > > People like you and me would opt-in. (well I would on some hosts) because >> > > we know what we're doing. Expert eyes get a look at it before it's forced >> > > onto our users, who are already leaving in leaps and bounds. >> > >> > Again, Pulse/PolypAudio seems to suggest that this is not the case. Why >> > didn't expert eyes who knew what they were doing migrate to that before >> > it become default? Or, alternatively, if the expert eyes which knew what >> > they were doing did migrate, why didn't they catch the bugs that others >> > encountered when it became default? >> > >> >> If us experts aren't even willing to opt-in in modest enough numbers to >> test it, why on earth would we force it on people at all? > > Well, here's are two simple facts for you: > > 1) if things are not used they tend to have bugs > 2) if things have bugs they are not used i am pretty sure that matches with most peoples opinion. infact thats why i am personally a rawhide user where i expect to have the newest things first (though it would be nice of the maintainer did do some basic tests himself to ensure atleast a working system for him personally before he pushed it into rawhide as default) to be able to really test it before i have to support people in #fedora with actually less technical expertize. change management is usually not about things that go wrong but about things that can go wrong. aka proper testing and planning before having "live/production" systems. it really wouldnt have hurt to test out the "complete system" means also all the raised potential issues on the checklist you do not feel responsible for as systemd maintainer. while everything might look shiny from one single point of view, there are definitely more povs. and while you personally dont care about some technologies we have like e.g. iscsi and alot others that were named... they might be critical to others. what i miss a bit personally is simply seeing potential implications for the users that are not capable of switching back to something else because they lack the expertize. or do not understand some wierd workarounds published somewhere to get stuff working because there wont be many how tos when the new system will go live. maybe trying to think from the perspective of a potential user when it is about a release would be a good approach. i am really curious what all turns out to be broken in the end... and no matter which systems fault it is. if it is coming up because of a too quick change i will definitely blame the process and the lack of testing/time to get things straight. That said, thanks for your effort in trying to improve a system. > > Acknowledging this: if you want to innovate you have no other option > than pushing things to the people, and then fix what breaks. but pushing them to end users vs experienced people first and give them enough time to report their problems is the key difference. > > And if you never are willing to pass something to the users before it is > 100% stable and tested, then it will never be 100% stable and tested, > and you simply stop to innovate. But that wouldn't be Fedora anymore > then. software is never 100% done or bugfree. but it appears to me you have a rather narrow view of only focussing your single system. but that system has to properly interact with other systems... no matter which side is to blame. > > And I think so far things went really well with systemd, even though > this discussion might create the impression it didn't. no it doesent at all. it does create the impression that some people would rather have a better change management for such critical components than what it currently appears to be. like stated above... change management is not about what happens or about gut feeling or confidence... it is about risk management. in reality every non technical user wont care if it is systemd or component xyz which is to blame. if it doesent work it doesent work... but especially if it worked before they wont see any improvement just a regression. if a simple text editor fails it is one thing. if a kernel fails you can still boot an old one (after you figure out how to display the grub menu...) but if an init system fails it doesent boot and the conclusion would in most cases probably be that you just install something else if you dont have enough skills to actually get it to work somehow or analyze the problem. Rudolf - also working for Red Hat, Inc. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
