RE: never say never...
--- Bill Barker [EMAIL PROTECTED] wrote: -Original Message- From: Wade Chandler [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 4:57 PM To: Tomcat Developers List Subject: Re: never say never... --- William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Anyways, many thanks to the Tomcat developers. I think almost every one of them are really great guys. I'm not certain how Amy is going to take that ;-). Wade Yes to be politically correct. :-D They are really great people. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
Haroon Rafique wrote: On Tuesday at 12:54pm, JB=Jay Burgess [EMAIL PROTECTED] wrote: JB The following comments are not intended to be a personal attack on JB anyone. However, I can't stand by and watch George speak my mind for JB me, word for word, and not chime in and say I agree!. Plus, I think JB if you took a poll, you'd find he speaks for a large number of list JB subcribers. JB Yes Jay, other members have that feeling too. If we take a look at the recent past, there are various examples of rudeness, impropriety and lack of respect. Well, my sympathies are more with the Tomcat developer team, given the abuse they incur from certain unfortunate individuals in the user community. There's the thread: http://marc.theaimsgroup.com/?t=11310796102r=1w=2 Subject: Sloppy, Lazy Tomcat Developers (Was: Persistent) which speaks volumes about how the tomcat dev community is turning people away. I checked the thread and didn't see anything wrong with what was stated by the Tomcat developers. They're only properly defending themselves against abuse from a disrespectful user. How would you expect any team to respond to an email with a subject of Sloppy, Lazy Tomcat Developers? Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
Glen Mazza wrote: Haroon Rafique wrote: On Tuesday at 12:54pm, JB=Jay Burgess [EMAIL PROTECTED] wrote: JB The following comments are not intended to be a personal attack on JB anyone. However, I can't stand by and watch George speak my mind for JB me, word for word, and not chime in and say I agree!. Plus, I think JB if you took a poll, you'd find he speaks for a large number of list JB subcribers. Yes Jay, other members have that feeling too. If we take a look at the recent past, there are various examples of rudeness, impropriety and lack of respect. Well, my sympathies are more with the Tomcat developer team, given the abuse they incur from certain unfortunate individuals in the user community. You mean by the same unfortunate individuals who like to abuse their checkout clerk, bank teller and doctor's receptionist? Odd, they tend to excuse themselves that they are paying for that privilage; Funny I don't recall seeing a donation check from them to the ASF. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
--- William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Glen Mazza wrote: Haroon Rafique wrote: On Tuesday at 12:54pm, JB=Jay Burgess [EMAIL PROTECTED] wrote: JB The following comments are not intended to be a personal attack on JB anyone. However, I can't stand by and watch George speak my mind for JB me, word for word, and not chime in and say I agree!. Plus, I think JB if you took a poll, you'd find he speaks for a large number of list JB subcribers. Yes Jay, other members have that feeling too. If we take a look at the recent past, there are various examples of rudeness, impropriety and lack of respect. Well, my sympathies are more with the Tomcat developer team, given the abuse they incur from certain unfortunate individuals in the user community. You mean by the same unfortunate individuals who like to abuse their checkout clerk, bank teller and doctor's receptionist? Odd, they tend to excuse themselves that they are paying for that privilage; Funny I don't recall seeing a donation check from them to the ASF. Bill I thought about not even writing this. Then I thought about not even submitting it. Don't take it personally how ever it hits anyone. I think it's fair. I think it runs both ways. I think most of the Tomcat developers are really great. I think an unnamed developer could learn how to be a little nicer. I think a good number of users could as well. There is no good excuse for simply being mean and nasty for users nor developers. Without mentioning any names: If one could see a list of what contracts and monetary connections are made through the Apache project for certain members they would see some things a little differently, and I do not mean that any of the developers deserve to be yelled at or belittled. For instance, I'm sure a few JBoss customers might find a couple of bugs and comments associated with them a little disturbing. I would imagine a few other commercial customers of other companies using projects based on Tomcat would as well. This based on my own experiences with aiding in explaining a couple of issues found in Tomcat. Some things do not require arguing about. They simply need to be looked at and egos need not get in the way. So, not to kick up the flames, just being real; I don't think it is as black and white as some people would like to believe in relation to volunteering hours to the project vs being compensated. The same can be said about Eclipse, Netbeans, etc. Many projects today have incorporated corporate interests into their ranks (whether it's admitted or not). Companies employ people to work on these projects, so they aren't doing it for free. Others are contributing their time to also utilize others time and selling products based on these open source projects and making a good amount of money doing so. Then some 3rd party softwares based on these solutions are bought by users. The company they purchased their software from spends money in donations or contributes developers to the projects. Money = Time and Time = Money. Lets face it, if these companies were not making money from from these open source projects they would not be contributing. They like the collective free time and work, which is also why many contribute to projects. Others contribute in their free time one way or another mostly just for fun. Anyways, many thanks to the Tomcat developers. I think almost every one of them are really great guys. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
On Tuesday at 12:54pm, JB=Jay Burgess [EMAIL PROTECTED] wrote: JB The following comments are not intended to be a personal attack on JB anyone. However, I can't stand by and watch George speak my mind for JB me, word for word, and not chime in and say I agree!. Plus, I think JB if you took a poll, you'd find he speaks for a large number of list JB subcribers. JB Yes Jay, other members have that feeling too. If we take a look at the recent past, there are various examples of rudeness, impropriety and lack of respect. There's the thread: http://marc.theaimsgroup.com/?t=11310796102r=1w=2 Subject: Sloppy, Lazy Tomcat Developers (Was: Persistent) which speaks volumes about how the tomcat dev community is turning people away. Constant threats of banning people don't help: http://marc.theaimsgroup.com/?l=tomcat-devm=113109876214068w=2 and http://marc.theaimsgroup.com/?l=tomcat-devm=113803462800300w=2 and http://marc.theaimsgroup.com/?l=tomcat-devm=113654919116826w=2 In addition, what does a guy need to do get his bug fixed??? I don't claim to be an expert by any means and the quality of the patch is not that great either, but come on: http://marc.theaimsgroup.com/?l=tomcat-devm=113024930913866w=2 Subject: solicit some interest in fixing bug 36847 (PatchAvailable) and http://marc.theaimsgroup.com/?l=tomcat-devm=113742608431361w=2 Subject: squeaky wheel gets the oil (so please fix bug 36847) So, yes, the persistent among us will keep trying but, for sure, a few of use will be turned away for good. Cheers, -- Haroon Rafique [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
2006/2/21, Costin Manolache [EMAIL PROTECTED]: No. Bill gave a wrong answer. He ignored in the fact that java.io.tmpdirand javax.servlet.context.tempdir are equivalent in implementation in Tomcat, and that to be compliant, Tomcat has to make java.io.tmpdir writable. File.createTempFile spec says that if a dir is not specified, the file must be created based on java.io.tempdir - which probably means it must be writable. Expressing frustration and anger can be healthy for you and maybe for the community - but it can't change much in terms of time people have to deal with the bugs and the user requests. +1 Please provide patchs, solutions, code to review and not anger/frustration !
Re: never say never...
At the risk of getting meta on everyone, I have to point out that something(?) similar seemed to happen to the CVS development several years back. I tuned out for a few years, and it seems like the entire (active) development group turned over. Maybe there is some sort of Anti-Pattern lurking in here... Is this a sign of ... what?
Re: never say never...
George Sexton wrote: This assumes that committers are an practically unlimited resource, and they Of course we have, because we actually own the Intellectual Property. You are forgetting that we have PMC (Project Management Committee), that is responsible to deal with all administrative stuff :) Actually, I've got two other submissions that are not in critical portions of the code: http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 From your bz report: ... I think to be compliant with the spec, this must be allowed. ... Again, I think the spec requires this. ... So, why would anyone even spend a single microsecond to look at the patch if *you* could not guarantee that the patch is compliant with the specs? Tomcat is very mature project, and lots of users are depending on it's stability. Considering a patch that it's own author considers as 'maybe' would lead us to nowhere. I applaud to your willing to contribute, but if you wish to do that, and eventually become a member of the elite, you must follow some rules, and the first one, like in any company is to respect your colleagues. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
On 2/21/06, Mladen Turk [EMAIL PROTECTED] wrote: Actually, I've got two other submissions that are not in critical portions of the code: http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 From your bz report: ... I think to be compliant with the spec, this must be allowed. ... Again, I think the spec requires this. ... So, why would anyone even spend a single microsecond to look at the patch if *you* could not guarantee that the patch is compliant with the specs? I don't intend to start (or enter) a flame war here, but you are making an interesting point. What about commiters changing behaviour of tomcat in a spec-free-zone, breaking tons of webapps worldwide, and replying to all bugzilla entries and comments with RESOLVED INVALID? regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
http://issues.apache.org/bugzilla/show_bug.cgi?id=38716 Yet another perfect example. This time its a WONTFIX, instead of INVALID, there is some progress to be observed :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
-Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 4:48 AM To: Tomcat Developers List Subject: Re: never say never... http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 From your bz report: ... I think to be compliant with the spec, this must be allowed. ... Again, I think the spec requires this. ... So, why would anyone even spend a single microsecond to look at the patch if *you* could not guarantee that the patch is compliant with the specs? I guess this is my mistake, for trying to sound humble. I was trying to be RESPECTFUL. I'll say it PLAINLY. Servlet Specification 2.4 says: SRV.3.7.1 TEMPORARY WORKING DIRECTORYS A temporary storage directory is required for each servlet context. Servlet containers must provide a private temporary directory for each servlet context, and make it available via the javax.servlet.context.tempdir context attribute. This just flat says that it must be there, and it is a working directory, which implies its writable. I applaud to your willing to contribute, but if you wish to do that, and eventually become a member of the elite, you must follow some rules, and the first one, like in any company is to respect your colleagues. Respect is a two way street. When someone like Bill Barker creates a logic puzzle as blatantly wrong as he did, then what level of respect is required? Specifically, Bill Barker's comments: Don't see the need. If you depend on this, your app is non-portable since there is no requirement that javax.servlet.context.tempdir has any relation to java.io.tmpdir. In fact, a servlet container is perfectly free to set java.io.tmpdir to /dev/null if it wants. Directory specified by java.io.tmpdir (which is what tomcat points javax.servlet.context.tempdir to) is now read, write, delete. Again, I think the spec requires this. I was fixing an implementation specific issue. The spec says that the container MUST make temporary working directories available. The IMPLEMENTATION that tomcat uses is to set java.io.tempdir and javax.servlet.context.tempdir So, my making that writable fixes an implementation specific issue for tomcat. I'll say it again in case I wasn't clear. 1) The spec says javax.servlet.context.tempdir must be a working directory 2) TOMCAT sets that value to the value of java.io.tmpdir THEREFORE FOR THE TOMCAT IMPLEMENTATION java.io.tmpdir MUST BE WRITABLE. So, in short. The ELITE should spend a little more time thinking about things instead of just reflexively trashing people. That is respect. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
-Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 4:48 AM To: Tomcat Developers List Subject: Re: never say never... http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 From your bz report: ... I think to be compliant with the spec, this must be allowed. ... Again, I think the spec requires this. ... So, why would anyone even spend a single microsecond to look at the patch if *you* could not guarantee that the patch is compliant with the specs? I guess this is my mistake, for trying to sound humble. I was trying to be RESPECTFUL. I'll say it PLAINLY. Servlet Specification 2.4 says: SRV.3.7.1 TEMPORARY WORKING DIRECTORYS A temporary storage directory is required for each servlet context. Servlet containers must provide a private temporary directory for each servlet context, and make it available via the javax.servlet.context.tempdir context attribute. This just flat says that it must be there, and it is a working directory, which implies its writable. I applaud to your willing to contribute, but if you wish to do that, and eventually become a member of the elite, you must follow some rules, and the first one, like in any company is to respect your colleagues. Respect is a two way street. When someone like Bill Barker creates a logic puzzle as blatantly wrong as he did, then what level of respect is required? Specifically, Bill Barker's comments: Don't see the need. If you depend on this, your app is non-portable since there is no requirement that javax.servlet.context.tempdir has any relation to java.io.tmpdir. In fact, a servlet container is perfectly free to set java.io.tmpdir to /dev/null if it wants. Directory specified by java.io.tmpdir (which is what tomcat points javax.servlet.context.tempdir to) is now read, write, delete. Again, I think the spec requires this. I was fixing an implementation specific issue. The spec says that the container MUST make temporary working directories available. The IMPLEMENTATION that tomcat uses is to set java.io.tempdir and javax.servlet.context.tempdir So, my making that writable fixes an implementation specific issue for tomcat. I'll say it again in case I wasn't clear. 1) The spec says javax.servlet.context.tempdir must be a working directory 2) TOMCAT sets that value to the value of java.io.tmpdir THEREFORE FOR THE TOMCAT IMPLEMENTATION java.io.tmpdir MUST BE WRITABLE. So, in short. The ELITE should spend a little more time thinking about things instead of just reflexively trashing people. That is respect. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
I applaud to your willing to contribute, but if you wish to do that, and eventually become a member of the elite, you must follow some rules, and the first one, like in any company is to respect your colleagues. Respect is a two way street. When someone like Bill Barker creates a logic puzzle as blatantly wrong as he did, then what level of respect is required? Specifically, Bill Barker's comments: You are pretty bad in taking examples. Bill nicely described the why nicely in nice words (don't know who is right or wrong, I don't care about that) and your answer to that is quite unapropiate. Especially the shouting. Just say you think he is wrong, because of xxx and everyone is happy.. In short : I think Bill gave a great answer and you didn't return that favour. And another thing : I (and others do to I guess) read bugzilla mails, so no need to copy paste that thing to a thread that has nothing to do with the thread (despite to what you seem to think). Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
-Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 11:24 AM To: Tomcat Developers List Subject: Re: never say never... You are pretty bad in taking examples. The example I took was specifically chosen because his comments are incorrect. I suppose I could have put his opening comments where he was baiting me but I chose to ignore those. Bill nicely described the why nicely in nice words Bill started out his comments by baiting me. Whether it was done nicely or not depends upon which side of the stick you're on. (don't know who is right or wrong, I don't care about that) If you don't know what is wrong or right how do you know Bill gave a great answer? It may have been a pleasant answer, but how can an answer be great if its not right? ) and your answer to that is quite unapropiate. Especially the shouting. Just say you think he is wrong, because of xxx and everyone is happy.. Mladen's comments were pretty intemperate as well. They were accusatory and belittling (joining the Elite trash). I think most people would be moved to shout at this point. In short : I think Bill gave a great answer and you didn't return that favour. No. Bill gave a wrong answer. He ignored in the fact that java.io.tmpdir and javax.servlet.context.tempdir are equivalent in implementation in Tomcat, and that to be compliant, Tomcat has to make java.io.tmpdir writable. And another thing : I (and others do to I guess) read bugzilla mails, so no need to copy paste that thing to a thread that has nothing to do with the thread (despite to what you seem to think). Mladen specifically referenced the issue. I felt it appropriate in my reply to reference the whole context. I re-posted the relevant portions to bugzilla after drafting the message. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
The following comments are not intended to be a personal attack on anyone. However, I can't stand by and watch George speak my mind for me, word for word, and not chime in and say I agree!. Plus, I think if you took a poll, you'd find he speaks for a large number of list subcribers. Whether you want to admit it or not, there has been a history of downright rudeness by certain people on this list when it comes to certain issues. The constant RESOLVED/INVALID and If you open it again, I will close it. comments need to stop. Besides the fact that they alienate potential useful members of the community, I think less time would probably be spent by all parties involved if the first answer to one of these issues was educational, instead of being rude and lacking useful feedback. Maybe George's raising this issue will make everyone think twice the next time they're about to dismiss one of these issues so quickly. Fortunately/unfortunately, there are are always going to be newbies and people that don't know enough about list protocol, etc. The professional response, though, is to treat every one of them with respect. Jay | Jay Burgess [Vertical Technology Group] | http://www.vtgroup.com/ -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 1:12 PM To: 'Tomcat Developers List' Subject: RE: never say never... -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 11:24 AM To: Tomcat Developers List Subject: Re: never say never... You are pretty bad in taking examples. The example I took was specifically chosen because his comments are incorrect. I suppose I could have put his opening comments where he was baiting me but I chose to ignore those. Bill nicely described the why nicely in nice words Bill started out his comments by baiting me. Whether it was done nicely or not depends upon which side of the stick you're on. (don't know who is right or wrong, I don't care about that) If you don't know what is wrong or right how do you know Bill gave a great answer? It may have been a pleasant answer, but how can an answer be great if its not right? ) and your answer to that is quite unapropiate. Especially the shouting. Just say you think he is wrong, because of xxx and everyone is happy.. Mladen's comments were pretty intemperate as well. They were accusatory and belittling (joining the Elite trash). I think most people would be moved to shout at this point. In short : I think Bill gave a great answer and you didn't return that favour. No. Bill gave a wrong answer. He ignored in the fact that java.io.tmpdir and javax.servlet.context.tempdir are equivalent in implementation in Tomcat, and that to be compliant, Tomcat has to make java.io.tmpdir writable. And another thing : I (and others do to I guess) read bugzilla mails, so no need to copy paste that thing to a thread that has nothing to do with the thread (despite to what you seem to think). Mladen specifically referenced the issue. I felt it appropriate in my reply to reference the whole context. I re-posted the relevant portions to bugzilla after drafting the message. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
Never mind. This isn't worth the heart-ache and I'm probably wrong about workdir being defined in terms of tempdir. I made this probably wrong assumption by looking at the startup scripts . George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 10:37 AM To: 'Tomcat Developers List' Subject: RE: never say never... -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 4:48 AM To: Tomcat Developers List Subject: Re: never say never... http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 From your bz report: ... I think to be compliant with the spec, this must be allowed. ... Again, I think the spec requires this. ... So, why would anyone even spend a single microsecond to look at the patch if *you* could not guarantee that the patch is compliant with the specs? I guess this is my mistake, for trying to sound humble. I was trying to be RESPECTFUL. I'll say it PLAINLY. Servlet Specification 2.4 says: SRV.3.7.1 TEMPORARY WORKING DIRECTORYS A temporary storage directory is required for each servlet context. Servlet containers must provide a private temporary directory for each servlet context, and make it available via the javax.servlet.context.tempdir context attribute. This just flat says that it must be there, and it is a working directory, which implies its writable. I applaud to your willing to contribute, but if you wish to do that, and eventually become a member of the elite, you must follow some rules, and the first one, like in any company is to respect your colleagues. Respect is a two way street. When someone like Bill Barker creates a logic puzzle as blatantly wrong as he did, then what level of respect is required? Specifically, Bill Barker's comments: Don't see the need. If you depend on this, your app is non-portable since there is no requirement that javax.servlet.context.tempdir has any relation to java.io.tmpdir. In fact, a servlet container is perfectly free to set java.io.tmpdir to /dev/null if it wants. Directory specified by java.io.tmpdir (which is what tomcat points javax.servlet.context.tempdir to) is now read, write, delete. Again, I think the spec requires this. I was fixing an implementation specific issue. The spec says that the container MUST make temporary working directories available. The IMPLEMENTATION that tomcat uses is to set java.io.tempdir and javax.servlet.context.tempdir So, my making that writable fixes an implementation specific issue for tomcat. I'll say it again in case I wasn't clear. 1)The spec says javax.servlet.context.tempdir must be a working directory 2)TOMCAT sets that value to the value of java.io.tmpdir THEREFORE FOR THE TOMCAT IMPLEMENTATION java.io.tmpdir MUST BE WRITABLE. So, in short. The ELITE should spend a little more time thinking about things instead of just reflexively trashing people. That is respect. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
No. Bill gave a wrong answer. He ignored in the fact that java.io.tmpdirand javax.servlet.context.tempdir are equivalent in implementation in Tomcat, and that to be compliant, Tomcat has to make java.io.tmpdir writable. File.createTempFile spec says that if a dir is not specified, the file must be created based on java.io.tempdir - which probably means it must be writable. Expressing frustration and anger can be healthy for you and maybe for the community - but it can't change much in terms of time people have to deal with the bugs and the user requests. Costin
never say never...
Hi List, please somebody explain: every few days, a strange procedure can be seen on this list. Somebody asks for improvement, suggests a fix or simply wants to discuss a new feature. Few minutes later, there is an answer from somebody, which tells us to ignore this subject, because it is not relevant. Is this necessary? Ok, sometimes we are too simple-hearted to understand all consequences of our suggestions. But IMHO, a one-line-answer is not going to help. Please, replace your go away, with I vote against it. (Even better would be some keywords for the green, so we can find some more wisdom.) R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
+1 =) Reinhard Moosauer wrote: Hi List, please somebody explain: every few days, a strange procedure can be seen on this list. Somebody asks for improvement, suggests a fix or simply wants to discuss a new feature. Few minutes later, there is an answer from somebody, which tells us to ignore this subject, because it is not relevant. Is this necessary? Ok, sometimes we are too simple-hearted to understand all consequences of our suggestions. But IMHO, a one-line-answer is not going to help. Please, replace your go away, with I vote against it. (Even better would be some keywords for the green, so we can find some more wisdom.) R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
RESOLVED | INVALID George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Reinhard Moosauer [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 11:09 AM To: tomcat-dev@jakarta.apache.org Subject: never say never... Hi List, please somebody explain: every few days, a strange procedure can be seen on this list. Somebody asks for improvement, suggests a fix or simply wants to discuss a new feature. Few minutes later, there is an answer from somebody, which tells us to ignore this subject, because it is not relevant. Is this necessary? Ok, sometimes we are too simple-hearted to understand all consequences of our suggestions. But IMHO, a one-line-answer is not going to help. Please, replace your go away, with I vote against it. (Even better would be some keywords for the green, so we can find some more wisdom.) R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
I really try to avoid these threads cause I'm not interested in debates nor the political aspects of open source projects and how they work, but the user brings up a good point, with a probable solution, and I don't see how a non committer response like the one below is even justified. I'm not intending to start a flame war here, just asking for a little bit more courtesy. Think about it, what would the tomcat project be without its users? Filip George Sexton wrote: RESOLVED | INVALID George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Reinhard Moosauer [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 11:09 AM To: tomcat-dev@jakarta.apache.org Subject: never say never... Hi List, please somebody explain: every few days, a strange procedure can be seen on this list. Somebody asks for improvement, suggests a fix or simply wants to discuss a new feature. Few minutes later, there is an answer from somebody, which tells us to ignore this subject, because it is not relevant. Is this necessary? Ok, sometimes we are too simple-hearted to understand all consequences of our suggestions. But IMHO, a one-line-answer is not going to help. Please, replace your go away, with I vote against it. (Even better would be some keywords for the green, so we can find some more wisdom.) R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
-Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 1:52 PM To: Tomcat Developers List Subject: Re: never say never... nor the political aspects of open source projects and how they work, This is a topic in which you should actually have a great deal of interest. Tomcat is a brilliant example of a project that has a totally dysfunctional leadership environment. On paper it is a meritocracy. This is great. The trouble is that the committers have power, without any real responsibility. For example, the responsibility to not be abusive towards others. So, committers can pretty much do anything without consequence. Just as a little example, several months ago I submitted a patch. One committer commented that he would -1 it for the com.sun imports. There weren't any com.sun imports, and when called on it the committer just gaffed me off. So, this committer just flat out lied (or was mistaken and when corrected denied the original error) about a reason for rejecting something. To be fair, the patch did have other problems that were legitimate issues. However, they should have been presented rather than a fairy tale invention. As far as how to structurally fix the tomcat group, my only feeble suggestion would be to permit TOMCAT USERS to recall or fire committers. Perhaps then some of the more egregious abuses would cease. but the user brings up a good point, with a probable solution, and I don't see how a non committer response like the one below is even justified. I was being ironic or sarcastic. I'm really not sure which. As for the part about non-committer, I just parroted back the #1 committer response to new bugs or requests entered into BugZilla. Often, when a users re-opens these events and asks why, they're re-closed with only RESOLVED | INVALID. If you don't like it (as I don't), go to the committers that do this. It seems to me that perhaps someone could do a little analysis and address the worst offenders. I'm not intending to start a flame war here, just asking for a little bit more courtesy. There won't be courtesy until those people who are the worst offenders are punished in some manner, or have their status as committers revoked. After all, why should they behave when there is no consequence? Think about it, what would the tomcat project be without its users? It would evidently be living in a state of open source purity where quality application design doesn't conflict with stupid people who want to use the software to solve business problems. The developers of the application who already live on a higher plane than the lowly users, without this interference achieve a higher state of consciousness. Perhaps they would even reach Nerdvana Filip George Sexton wrote: RESOLVED | INVALID George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
George Sexton wrote: Whilst I agree with the general thrust of the arguments made so far in this thread I do take serious issue with one of your statements. Just as a little example, several months ago I submitted a patch. One committer commented that he would -1 it for the com.sun imports. There weren't any com.sun imports, and when called on it the committer just gaffed me off. This is not an accurate representation of the facts. The thread can be read here: http://marc.theaimsgroup.com/?l=tomcat-devr=1s=allowedAliasMatchesq=bw=4 The commit Bill was referring to is this one: http://marc.theaimsgroup.com/?l=tomcat-devm=111788844800136w=4 that includes +import com.sun.org.apache.bcel.internal.generic.ALOAD; Bill did not gaff you off. He pointed out he was -1 for the commit on the basis of the import. He also expanded on other areas he had concerns over. So, this committer just flat out lied (or was mistaken and when corrected denied the original error) Accusing someone of lying is a serious allegation and on the basis of the dev archive clearly not true in this case. I would urge you to retract your comment. Often, when a users re-opens these events and asks why, they're re-closed with only RESOLVED | INVALID. If you don't like it (as I don't), go to the committers that do this. It seems to me that perhaps someone could do a little analysis and address the worst offenders. I agree that closing bug reports without an explanation is rarely, if ever helpful. A few lines explaining why the bug is invalid / won't be fixed would help enormously. That being said, having spent that last couple of years fixing bugs it is immensely frustrating when having closed a bug report as invalid (with an explanation and where appropriate a reference to the spec) it is re-opened with a comment that clearly indicates that the person re-opening the bug report hasn't bothered to read the previous comments or the spec. There is an argument that goes along the lines of If the person creating the bug report can't be bothered to read the spec / do some basic fault finding / provide enough information to reproduce the fault / read http://tomcat.apache.org/bugreport.html etc why should I be bothered to explain things to them?. Whilst I do not agree with this view personally, I can see how people have reached this point and I do understand the frustration they feel. To some extent, the old maxim Garbage in, garbage out applies. The community nature of open source is such that the quality of response you receive is generally directly proportional to the effort you are prepared to put in. There are always exceptions but in my experience this rule of thumb applies far more often than it doesn't. There won't be courtesy until those people who are the worst offenders are punished in some manner, or have their status as committers revoked. After all, why should they behave when there is no consequence? I don't think that punishment is the answer. If you feel someone is discourteous point it out (privately or publicly - your choice) and ask them to modify their behaviour. Above all, don't descend to their level. Think about it, what would the tomcat project be without its users? Indeed. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
-Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 4:02 PM To: Tomcat Developers List Subject: Re: never say never... George Sexton wrote: Whilst I agree with the general thrust of the arguments made so far in this thread I do take serious issue with one of your statements. Just as a little example, several months ago I submitted a patch. One committer commented that he would -1 it for the com.sun imports. There weren't any com.sun imports, and when called on it the committer just gaffed me off. This is not an accurate representation of the facts. The thread can be read here: http://marc.theaimsgroup.com/?l=tomcat-devr=1s=allowedAliasM atchesq=bw=4 The commit Bill was referring to is this one: http://marc.theaimsgroup.com/?l=tomcat-devm=111788844800136w=4 that includes +import com.sun.org.apache.bcel.internal.generic.ALOAD; Bill did not gaff you off. He pointed out he was -1 for the commit on the basis of the import. He also expanded on other areas he had concerns over. So, this committer just flat out lied (or was mistaken and when corrected denied the original error) Accusing someone of lying is a serious allegation and on the basis of the dev archive clearly not true in this case. I would urge you to retract your comment. I stand corrected. The referenced import must have been added by Peter Rossbach when he committed it. My submitted code did not have the com.sun import. This is why I didn't think it was there. When the comment was made, I reviewed my submission and didn't see it. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
-Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 4:02 PM To: Tomcat Developers List Subject: Re: never say never... I agree that closing bug reports without an explanation is rarely, if ever helpful. A few lines explaining why the bug is invalid / won't be fixed would help enormously. I think everyone is in agreement here. That being said, having spent that last couple of years fixing bugs it is immensely frustrating when having closed a bug report as invalid (with an explanation and where appropriate a reference to the spec) it is re-opened with a comment that clearly indicates that the person re-opening the bug report hasn't bothered to read the previous comments or the spec. There is an argument that goes along the lines of If the person creating the bug report can't be bothered to read the spec / do some basic fault finding / provide enough information to reproduce the fault / read http://tomcat.apache.org/bugreport.html etc why should I be bothered to explain things to them?. Whilst I do not agree with this view personally, I can see how people have reached this point and I do understand the frustration they feel. Having a cycle of 4-8 iterations where a person asks why its resolved invalid, and a committer re-marks it resolved invalid without comment doesn't seem like it would reduce frustration on the part of the committer. It seems to me they would just get angrier on each iteration. Don't misunderstand me. I'm certainly not saying a committer shouldn't say This is non-compliant and will not be addresed or We comply with the spec, and we will not be expanding the application to meet your specific need. These are legitimate responses. When the specification is involved, it would be nice to reference the relevant part of the specification. When committers use emotionally charged terms with no technical basis, or just reject things out of hand without explanation its not fair. There won't be courtesy until those people who are the worst offenders are punished in some manner, or have their status as committers revoked. After all, why should they behave when there is no consequence? I don't think that punishment is the answer. If you feel someone is discourteous point it out (privately or publicly - your choice) and ask them to modify their behaviour. Above all, don't descend to their level. This is how things should be done there is just one small flaw. Those people who are the worst offenders in this matter are pretty much unaffected by this approach. If people consistently don't respond to that approach (which should be first), then there needs to be some recourse. For example, a popular book recommends this approach to conflict resolution: 1) Approach the person directly. If that doesn't work. 2) Approach the person with others as witnesses to verify what is said. If the person still doesn't respond: 3) Take the person before the community. If the person still doesn't respond. 4) Eject the person from your community and have nothing further to do with them. While your recommendation is sound, and is indeed step 1 as outlined above, by itself it is not enough. There need to be steps to take if the person doesn't respond. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
George Sexton wrote: Don't misunderstand me. I'm certainly not saying a committer shouldn't say This is non-compliant and will not be addresed or We comply with the spec, and we will not be expanding the application to meet your specific need. These are legitimate responses. Agreed. When the specification is involved, it would be nice to reference the relevant part of the specification. Also agreed. When committers use emotionally charged terms with no technical basis, or just reject things out of hand without explanation its not fair. To be fair, there is a technical basis 99.9% of the time but in the past it often hasn't been explained. As stated elsewhere in this thread, adding the explanation helps a lot. On the subject of fairness, is it fair that someone who is too lazy to read the spec / read the docs / etc should take up any more of the community's time than the absolute minimum required to, for example, mark the bug as INVALID? This isn't a view I advocate but it is one I understand. This is how things should be done there is just one small flaw. Those people who are the worst offenders in this matter are pretty much unaffected by this approach. If people consistently don't respond to that approach (which should be first), then there needs to be some recourse. For example, a popular book recommends this approach to conflict resolution: I can see the sense in this approach but ejecting someone is pretty much impossible in an open source community. Anyone who is 'banned' can easily get a new e-mail address and re-join. The best you could achieve would be ignoring them. You can always set an e-mail filter ;) You might also be interested in this thread. It was a discussion about how to handle misbehaving members of another part of the Apache community: http://www.mail-archive.com/community%40apache.org/index.html#04172 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
-Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 5:33 PM To: Tomcat Developers List Subject: Re: never say never... On the subject of fairness, is it fair that someone who is too lazy to read the spec / read the docs / etc should take up any more of the community's time than the absolute minimum required to, for example, mark the bug as INVALID? This isn't a view I advocate but it is one I understand. OK, let's throw out the whole fairness thing. How can the Tomcat committers most efficiently, and with the least amount of anger, hate, and discontent handle people who do not put in a reasonable effort to understand things or submit reasonable defect reports. Candidates are: 1) Committer marks it resolved | invalid. Submitter demands to know why. Committer re-marks it RESOLVED | INVALID, ad infinitum until some other committer decides to break the cycle. Nobody's really happy with this. 2) The committer puts in a minimal reason referencing the spec. To make most people happy, a reference to the specific portion of the spec would have to be researched. The user learns nothing, and the committer is answering questions instead of fixing code. 3) The committer marks it resolved | invalid, and sends the user to the ESR paper on How to ask questions the smart way. Since the committer could save this snippet of text and copy and paste the text, it seems like it wouldn't be hard. This would hopefully educate the user and result in higher quality submissions in the future. If I've missed any solutions I'd be interested in them. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
A disclaimer here - I used to have committer status (and might still). On 2/20/06, George Sexton [EMAIL PROTECTED] wrote: As far as how to structurally fix the tomcat group, my only feeble suggestion would be to permit TOMCAT USERS to recall or fire committers. Perhaps then some of the more egregious abuses would cease. This assumes that committers are an practically unlimited resource, and they are not. The answer is very simple. If you want a better job done, become a committer, and do the better job you want to see done. If your answer is that you do not have time - then lack of time is also the answer to your question. Time is a limited resource, and this is a all-volunteer effort. You cannot write a check against someone else's time. Allowing non-contributors to fire contributors is unlikely to be constructive. To be constructive you need to contribute. On the other hand, I don't want to hit this one too hard. Clearly you made an attempt to contribute - and that's great! You also recognized that there were issues with your contribution - that also is a good thing. If the answer you got seemed a bit too aburpt (and perhaps it was), then do try to understand that the other guy may not have the abundance of time to be optimally diplomatic. In other words, please keep trying...
RE: never say never...
-Original Message- From: Preston L. Bannister [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 6:22 PM To: Tomcat Developers List Subject: Re: never say never... A disclaimer here - I used to have committer status (and might still). On 2/20/06, George Sexton [EMAIL PROTECTED] wrote: As far as how to structurally fix the tomcat group, my only feeble suggestion would be to permit TOMCAT USERS to recall or fire committers. Perhaps then some of the more egregious abuses would cease. This assumes that committers are an practically unlimited resource, and they Actually I don't make that assumption and I also don't assume that users will randomly fire all committers. I don't think my proposal would induce a shortage. were issues with your contribution - that also is a good thing. If the answer you got seemed a bit too aburpt (and perhaps it was), then do try to understand that the other guy may not have the abundance of time to be optimally diplomatic. In other words, please keep trying... Actually, I've got two other submissions that are not in critical portions of the code: http://issues.apache.org/bugzilla/show_bug.cgi?id=38352 http://issues.apache.org/bugzilla/show_bug.cgi?id=38508 Perhaps they will get picked up. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
