james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: [Mime4j] 24 Test Failures
Date Mon, 21 Jul 2008 20:02:48 GMT
On Mon, Jul 21, 2008 at 21:58, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Mon, Jul 21, 2008 at 8:52 PM, Bernd Fondermann
> <bernd.fondermann@googlemail.com> wrote:
>> On Mon, Jul 21, 2008 at 17:40, Stefano Bagnara <apache@bago.org> wrote:
>>> Niklas Therning ha scritto:
>>>> Stefano Bagnara wrote:
>>>>> So you prefer to not have bug-proving tests. I just understood this,
>>>>> this is simply a matter of preference, so rather than disappoint each
>>>>> we can discuss a common way to deal with this.
>>>>> Most of them have opened threads/jiras waiting for more input, feel free
>>>>> to add your knowledge to that threads so we can close them ASAP.
>>>> My preference is to have tests that pass in trunk. I'd rather have the
>>>> test cases that prove a bug in JIRA. Once a bug has been fixed the test case
>>>> will of course be added to trunk to prove that it has been fixed.
>>>> /Niklas
>>> How do you (you all) suggest to deal with situation like the recent
>>> MIME4J-59 that made 3 tests to fail?
>>> 1) Should we wait committing a fix for a critical bug until we are sure all
>>> tests pass?
>>> 2) Should we commit them and leave the new test failing (to be solved ASAP
>>> but not a requirement for the author of the first fix)
>>> 3) Should we remove the failing tests and open a JIRA issue with them?
>>> My preference goes to #2.
>> -1 to 2).
>> Many failing tests for hard-to-fix bugs in trunk is not good because
>> it obviously frustrates active contributors (though not every single
>> contributor, I have to admit). I am investing at least 30 minutes a
>> day currently just to read mime4j mail, the pure volume is
>> overwhelming. So I can imagine that running into a broken trunk from
>> one day to another is not fun.
>> I saw at least 3 hands from active mime4j contributors raised asking
>> (explicitly or implicitly) to slow down (which is a majority) so I
>> propose to do exactly that.
> it's great that Mime4J is being pushed forward: it's just a question
> of directing energy most productively

+1, exactly. I was not intending to imply that we should stop or move
backwards. Just make everybody able to contribute and keep the flow.
Make sure everybody is heard, recognized and understood.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message