Some comments inline.

On Wed, May 19, 2010 at 1:44 PM, Adriano dos Santos Fernandes <
adrian...@gmail.com> wrote:

> On 19/05/2010 14:49, Jeremy Thomerson wrote:
>
>> How about we put the request back on you:
>>
>> Please prove that WICKET-2846 DOES introduce a nasty regression.
>>
>> This is much easier to prove / disprove than what you request.
>>
>>
> Jeremy, as an open source developer, I understand your position and what
> you said. However, I also understand that the Wicket team could consider the
> problem I'm bringing to you. I'm sure your team could understand what I
> said, and may explain if I'm wrong. My experience with this, however, is
> that it make Wicket another piece of the stack to introduce an evil problem.
>

Yes, we can (and will) consider it.  And we can understand it.  But you
can't say that Wicket "introduce[s] an evil problem" - since you yourself
have said that you do NOT know if it introduces a problem.

See the bug I shown, for example. Guice team just make they counterpart open
> till now. Wicket could do the same, but as this is a new "improvement", it
> looks for me that its consequence was not well know, as this isn't essential
> for the framework.
>

I'm not sure what you mean about Guice.


> As a user, needing to do our applications, we haven't even time to upgrade,
> so we're still in 1.4.1.
>
> As my vote didn't really count (it's non binding, after all), voting
> against is just a way to show my in-satisfaction with something I considered
> a problem. Note that I have (re)opened bug reports that matter for us, and
> I'm not one that vote against due to it.
>

But we still value votes.  But, you can't vote against something because you
*think* it *may* *possibly* have a bug.  If, however, you could spend
fifteen to thirty minutes creating a quickstart that proves that there is a
bug, then we would probably vote against this release ourselves.  That's the
reason we open it up to the dev list - so that people can test that there
are not regressions.

Bottom line is that we fix bugs, but we can't go and do the legwork for
everyone who says "oh, I think this may be a bug".  There are very
reasonable responses on the other thread as to why this will *not* create a
bug - that if the threads are still running, it's a bug in why you're
running threads still during a redeploy.  The reference to the application
that gets copied in the InheritableThreadLocal will die when the thread
does.  So, how will this introduce a bug?

--
Jeremy Thomerson
http://www.wickettraining.com

Reply via email to