Bernd Fondermann ha scritto:
On Mon, Jul 21, 2008 at 17:40, Stefano Bagnara <[EMAIL PROTECTED]> 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
time.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
