I am also often pissed off with how tapestry is handeling the comunity,
but you should remember that if you want to add a class (like the patch
you sent) it is not neceserily a bug, its a wish, and wishes are... how
should i say it... well, free? This "patch" you posted - there is no
problem of placing it in your classpath and using it, you *don't* need
tapestry to have it in the codebase to use it, and its not a bug which
prevents you going on...
now about real bugs - like Jesse said its open source, but I guess he
forogt something important and that is - you don't need the tapestry
team in order to apply your patches :
Fix the bug,
create a patch,
apply the patch,
build tapestry,
bug is gone,
post the patch to jira.
If you don't do it this way, and complain that bugs are not being fixed,
well... a part from open source is interaction with the community.
Some people understand "interaction" as "I submit a bug and you fix it"
- may be, and then again, may be not...
Cheers,
Ron
ציטוט Leonardo Quijano Vincenzi:
Jesse Kuhnert wrote:
There is such a thing as creating a patch you know. Being ignored after
submitted a very acceptable patch and being ignored after submitting a
bug
request are two very different things. I think with open source
projects you
kind of have to either pay for it/fix it yourself/wait until it's
fixed for
you. I know the first option is available by going to
tapestrysupport.com<http://tapestrysupport.com>;)
Oh yes. There also such a thing as feedback. I contributed once a patch
to this project, only to see that it's sitting around hoping someone
will look at it:
http://issues.apache.org/jira/browse/TAPESTRY-628
This is a simple patch for what I was asking for, it just adds a file to
the codebase, and that's it. Sure, it needs some work, but its a good
start.
But it's still floating around.
Now, for this other issue:
http://issues.apache.org/jira/browse/TAPESTRY-735
I didn't provide a patch, but rather asked for feedback. I just wanted
to know if it was worth it to present a patch (if it was going to be
included). The component is very handy, it allows to include Javascript
functions that invoke listeners. Dump LinkSubmit and add this JS
function to any DirectLink, PageLink, etc. A nice refactoring.
For the exception error, IMO it's a simple catch you have to add:
http://issues.apache.org/jira/browse/TAPESTRY-671
But a frequent (and annoying) trend JIRA-based projects have it's that
developers close issue reports after rejecting them. In the Bugzilla
days, one could re-open an issue. Here we can't. Ignoring subsequent
comments to the JIRA issue is just rude and inconsiderate to the people
that are contributing to the project (don't worry, Gavin King of
Hibernate also does that - maybe jboss's last 4 letters have gone to his
head and it's regrettable to see, for a guy - me - that has been
involved in that project since 2002). I don't like spamming JIRA
databases, so I'd rather whine here in the developer's list.
For the redirect error:
http://issues.apache.org/jira/browse/TAPESTRY-607
I didn't provide a patch, since I was exploring the functionality. I
*did* explore the bug, and said (in the issue, that wasn't reported by
me) that it was caused by an incorrect reset() on internal forwards, and
that Tomcat didn't allow for the encoding to be changed after a reset()
in the same request.
Anyway. I'm just trying to help. But providing patches / errors request
when nobody's reading them, well ... I have a job, too. I can't waste my
time talking to the wall.
Somewhere around here Geoff was complaining about something similar. IMO
his bug was not as critical as he thinks, but I agree with him in that
the problem is that "nobody cares!"
So, my opinion is, if maintainers don't have time to keep up with all
the bug reports, then get more developers involved! Maybe it's better to
do a code freeze for 4.0. Cool! Then go fix the bugs, but don't go
talking about doing a RC if you still have nasty errors.
I'm all into contributing to open source projects. It contributes with
my work and I can give something back. But there are
'developer-friendly' projects and there are 'ego-friendly' ones. If a
developer provides a patch, or provides a detailed bug report, or asks
for feedback on a complex issue, it's not a good idea to ignore him.
We're open source developers, not beggars.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
