james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [Mime4j] 24 Test Failures
Date Tue, 22 Jul 2008 07:09:03 GMT
Bernd Fondermann ha scritto:
> 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, but
>>>> this is simply a matter of preference, so rather than disappoint each other
>>>> 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).

What is your preference? Both #1 and #3?

> 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).

Maybe this depends on your definition of "hard to fix". Technically each 
of them requires much less time than each of this threads. The issue is 
instead a matter of GOAL.
You can see as an example the recent MIME4J-54 topic: everyone but Serge 
agree that it require a fix (like I proposed). I will not ignore Serge, 
I instead prefer to discuss while we can't find a solution.

I think we would just need more people with *knowledge* about the RFCs 
and real world implementations to make this discussions shorter. THey 
will instead require much more time because we have to learn in the mean 

> 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.

Bernd, you are not working on mime4j, ATM. It is ok if you don't catch 
up with technical discussions about solving specific issues.

My complaint is about the fact that what we had in mime4j was not 
different from what we had in JAMES Server multiple times (in that case 
caused by Robert) and I don't see why we should use similar tones/moods 
in a collaborating environment.

It seems that MIME4J was working like a charm and the failing tests have 
been removed in few hours (most of them in few minutes after someone 
asked for this).

> 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.

I'm not sure I read anyone asking to slow down. Maybe I'm not good at 
reading implicit requests, here.

Do we want to put a maximum number of messages to be written daily to 
the mailing list so that inactive developers have a chance to read them? 
Nonsense to me.
Discussion happens by replying each other: this means that we have a 
long discussion including many messages when at least 2 developers are 
discussing. I think there is nothing bad with this. I instead think it 
is bad when the messages are full of complaints or personal criticism. 
Technical discussion a collecting majority opinion about GOALs and 
specific issues solutions is indeed very important.


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

View raw message