On Tue, Jan 18, 2011 at 11:34:23AM +1100, Simon Burge wrote: > Why was this removed when there was an active discussion about removing > it where no concensus was reached? This sort of thing where commis > occur before a discussion is finished seems to be occurring more and > more often.
Maybe because the whole tech-userlevel@ mailing list has become poisonous? I know several people who abstain from posting anything to the list because of the nature of the list and these discussions. If one can not use his or her own discretion with what must be one of the most trivial files in the system, there is something fundamentally wrong. It is easy to block and freeze things (even by an user) simply by posting regularly to tech-userlevel@ just to show that there was no "consensus". If there would be a textbook about bike shed, operator(7) would be a good examle. I'll end this with couple of quotes from Poul-Henning Kamp[1]: "Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions." "A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is *here*." This is a real problem. It can be hard to get actual code review, but there are plenty of people who are willing to "help" you with a bike shed. You can make commits deep in the kernel without anyone noticing, but once it is about the holy operator(7), everyone needs to have an opinion. "I do know that reasoning will have no power to stop such 'reactionaire conservatism'. It may be that these people are frustrated about their own lack of tangible contribution lately or it may be a bad case of 'we're old and grumpy, WE know how youth should behave'." "Either way it is very unproductive for the project, but I have no suggestions for how to stop it. The best I can suggest is to refrain from fuelling the monsters that lurk in the mailing lists: Ignore them, don't answer them, forget they're there." Indeed. - Jukka. [1] http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg05634.html
