You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Reinhard Moosauer <re...@mib1.de> on 2006/02/20 19:08:50 UTC
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
+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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Leon Rosenberg <ro...@googlemail.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 2/21/06, Mladen Turk <mt...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by "Preston L. Bannister" <pr...@gmail.com>.
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...
Posted by Henri Gomez <he...@gmail.com>.
2006/2/21, Costin Manolache <co...@gmail.com>:
>
> > 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...
Posted by Costin Manolache <co...@gmail.com>.
> 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
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Martin van den Bemt [mailto:mllist@mvdb.net]
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Martin van den Bemt <ml...@mvdb.net>.
>
>>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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Mladen Turk [mailto:mturk@apache.org]
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Mladen Turk [mailto:mturk@apache.org]
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Mladen Turk <mt...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Preston L. Bannister [mailto:preston.bannister@gmail.com]
> 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 <gs...@mhsoftware.com> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by "Preston L. Bannister" <pr...@gmail.com>.
A disclaimer here - I used to have committer status (and might still).
On 2/20/06, George Sexton <gs...@mhsoftware.com> 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...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> 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-dev&r=1&s=allowedAliasM
> atches&q=b&w=4
>
> The commit Bill was referring to is this one:
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=111788844800136&w=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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Mark Thomas <ma...@apache.org>.
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-dev&r=1&s=allowedAliasMatches&q=b&w=4
The commit Bill was referring to is this one:
http://marc.theaimsgroup.com/?l=tomcat-dev&m=111788844800136&w=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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
> -----Original Message-----
> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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:reinhard@mib1.de]
>> 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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by George Sexton <gs...@mhsoftware.com>.
RESOLVED | INVALID
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
> -----Original Message-----
> From: Reinhard Moosauer [mailto:reinhard@mib1.de]
> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org