Casey Dahlin pÃÅe v Ät 16. 12. 2010 v 11:19 -0500: > On Thu, Dec 16, 2010 at 12:27:34PM +0000, Richard W.M. Jones wrote: > > What you don't understand is that you are throwing away the experience > > and knowledge of thousands of Unix system administrators. Almost of > > all of them do not even read this mailing list. > > > > Rich. > > I hate this argument. > > The "experience and knowledge" claim applies to everything we could possibly > change. > > Change.\nIs.\nGoing.\nTo.\nHappen. That's a too black-and-white view. Of course there is and will be change - what would we all be doing here if there were nothing to change, after all? The thing that needs to be appreciate is that every change has _costs_ on the user-base. I can't quickly find out good numbers on the number of server users of Fedora and Fedora-derived distributions; based on http://www.centos.org/modules/newbb/viewtopic.php?topic_id=18728&forum=14 , let's stipulate that there are 1,000,000 installations (which is almost certainly a huge understatement), with 10 servers per administrator on average, so 100,000 Linux system administrators. Better numbers would be welcome. * You simplify existing code, which changes a rarely-used configuration value that "shouldn't affect anything in most cases", nevertheless requires a release note. Say 10% of the system administrators reads the release notes, and reading the release note takes 10 seconds. The code simplification just cost our userbase more than 3 working days, with nothing to show for it. Did the code simplification save the programmers 3 days, so that at least overall there was a net benefit? * You replace a configuration file, or change its syntax, so that old knowledge and old kickstart scripts no longer apply. Say, again, that this change affects 10% of the system administrators, and that the change is fairly trivial, so reading the documentation and updating existing configuration scripts takes only 1 hour, and validating the change and the associated administrative overhead (keeping track of the change) takes 3 hours. Now the configuration file change has cost our userbase about 19 working _years_. To be worth it across the population of system administrators, the change needs to save the average system administrator 24 minutes before the configuration method changes again, or provide some other equivalent benefit. Saving the average system administrator 24 minutes is not easy (try thinking of a configuration change that would do that), and the more frequent changes of the configuration are, the more pronounced the benefits of the feature need to be. * You replace a whole subsystem, requiring _each_ system administrator to study the new subsystem for 10 hours, and to update the existing configuration, validate it and so on, which takes 30 hours. The change has cost our userbase a working week; to be worth it, it also needs to save each system administrator a working week. Again, the more frequent the subsystem changes are, the more pronounced the benefits of the changes need to be. So, yes, change is going to happen, and some change is clearly good. But when there are 10 programmers on a project and 100,000 users, each change has to be _very obviously_ good, or it might be better avoided. Especially minor changes that don't bring any measurable benefit (perhaps making the system "cleaner" or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Mirek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
