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.
--
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software
p.s.: Please, please don't fall in the trap of releasing a bad product /
bad documentation and then force people to go to TapestrySupport.com.
It's just unprofessional. I'm not saying you are doing it, but then..
don't do it, really... (I have enough with JasperReports's lack of
documentation and all the ads promoting JasperSoft. Sorry, but I'd
rather see a complete project before thinking of paying support for it).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
