Les, Charlie, devinfo list members, Sorry for this continuing rant on policy. -------
> > From: Paul Miller [mailto:[EMAIL PROTECTED]] >> >> And I thought it is the right/responsibility of the developer to >> accept/reject/ignore any and all suggestions from the community with >> priority given to developing good code. Do you think Linus >> incorporates every patch or even responds to all of them? I don't see >> complains about his policy. This isn't slashdot where anyone can >> create an agenda and vent their frustration. > >The issue isn't what bugs get fixed or how, it is whether all of the >existing bugs have to be a surprise to everyone who attempts to >test the beta versions. I don't think you will see Linus (or RedHat) >doing anything to make communication among beta testers difficult >because they understand the value they add when properly encouraged. I don't see MITEL staff making communication difficult or discouraging beta testers. I know from personal experience that when one is overwhelmed with off topic questions you eventually "hit a wall" and your performance as a human drastically deteriorates. The more you care about the list, the deeper you get dragged into policy disputes. As the list mom you are damned if you police the list and damned if you don't. It only takes a few list participants to create uncertainty and confusion. > >> It seems like this list continues to gain immature members who offer >> criticism on policy but no practical information. > >I post my viewpoint because the policy affects me directly. Admittedly >I have installed SMEserver on several machines, only one of which >has paid service but still the consumer experience is the same. From the e-smith policy statements and posts I see no shame in "admitting" that you have SME server on several machines. The software is free, it is open. MITEL charges for service and makes commitments based on those charges. In my mind that means you can intall SME server on as many machines as you want, you can modify it as you want and you can, as long as you comply with the license, modify it, sell it and support it. That SHOULD be enough stimulate any fair minded person to ask well thought out questions that serve to improve the product for all our benefit. However, if you want to dictate policy, demand service from MITEL, use their forums as an advertising channel for your products or services or their servicemark to make money you should ethically expect to compensate them. There is a wealth of information on the free, searchable forums that allow consumers to exploit the efforts of all contributors. I do not think non paying consumers or testers have a right to demand anything beyond what is freely offered or any kind of guarantee or to be personally critical of individuals. I also believe that it is the responsibility of those who have questions to consider the impact of their request on a volunteer service organization that has limited resources and not ask questions designed to push e-smith staff buttons on policy issues as I have observed a very few devinfo participants do time and time again on this list. >I don't expect any software to be bug-free, but I really don't >like unnecessary surprises which is why I spend time on lists >such as this one. Examples of things I feel should have been >discussed, and which caused problems on my production machines >are the change in meaning of 'everybody' (from any user that can >access the network to only users with logins on this machine) and >the change to disallow 'local networks' that don't have a router >specified that can be reached through the local network interface. I am sure that each devinfo contributor has an item where they think e-smith could improve. So why don't we see more contributors post details of what is wrong and how they would right what is not necessarily broken but needful of improvement? >I'm sure these have caused lost production time for others also >that could have been avoided if the different behavior had been >mentioned on the mailing list by the first one who noticed it. >After the fact, I surmise that one of these changes was an >intentional tightening of security, the other is a bug. To be concerned about lost production time on devinfo seems to me to be pushing it. After all, one should not be using the relatively untested items on devinfo for production in a business. >These are just examples that happened to affect me. I don't mean >to single them out as unusual problems or make any demands about >fixing them. I think they are typical of problems that will always >exist and the best defense is the early warning we could give each >other if bugs were a permitted topic here. Since this community is all volunteer, and this is open source, any interested party could theoretically volunteer to set up and host their own devinfowarning list as a free service to others. I am sure they would learn much from the experience, would benefit from the pride of accomplishment, would shun any material reward and benefit hugely from community recognition. In short, I don't think its appropriate for devinfo participants to try to dictate policy on devinfo and I don't think it would be useful for e-smith to change their policy on bugs. Best Regards, Paul -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
