Robert Burrell Donkin ha scritto:
On Mon, Jul 21, 2008 at 3:09 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Mon, Jul 21, 2008 at 2:37 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
<snip>
PS: "dispirited" and "disappointed" and "this is a complete mess" seems a
bit out of contest in a collaborative environment.
i am disappointed that mime4j cannot be build and that the last good
build is over 10 days ago
I'm disappointed too for this. Who should we blame?
let's not talk about blame but about how we can go forward from here.
given the number of changes which have been made we need to test
Mime4J against JAMES trunk ASAP. this means that the test suite needs
to pass.
I totally agree, that's why I was disappointed by your disappointment ;-)
I already done what was in my possibility to reduce the number of
failures. I need feedback for the other issues.
i'm dispirited because i finally have a day off to catch up on JAMES
stuff and (yet again) i find that i can't work on IMAP because MIme4J
can't be built
Just build it anyway. You can ignore failures because they should not be
*new* bugs, but older bugs that simply have a proving test now.
ignoring failures is a bad idea: it's too easy to introduce
regressions into the Mime4J codebase.
I'm not sure I understand. The failures I see are "known" and are not
regressions (they are there to prove we have bugs, we have since more
than 10 days). If you see more failures just report them: I'm sorry I
can't fix issues I don't see ;-)
Everyone is working to fix bugs here, and you may notice most bugs have
not
been introduced by the one that reported them or are investigating on
fixing
them. If we like to use this words it is disappointing that we have so
many
regression since 0.3, but I never used this word because I'm used to work
in
similar projects and I know this simply happens.
some undocumented and untested behaviour has regressed but this does
not justify breaking the test suite
breaking the test suite??? We added new tests to prove the existence of
bugs.
adding tests without fixes breaks the test suite
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.
I moved any message I wrote for proving bugs to their JIRAs, so that
they should not break the test suite (I don't like this, but I like even
less to have disappointed collaborators).
Unfortunately we removed many messages from the test suite so we had a less
complete test suite in the current implementation. This led to regression,
and this simply happens (I'm not telling that it's your fault).
i'm not bothered about fault finding: i'm just concerned that Mime4j is broken
I'm concerned too. Should we revert Niklas fix until we have a better
solution? I don't think so.
I don't think that the mime4j we had previously (not handling
quoted-printable text) was any better than what we have now.
If you want tests to pass then IMHO the best option ATM is to fix the
quoted printable issue, or, if noone can deal with this in short time to
simply comment the 3 failures in MessageWriteToTest.
An issue was about boundary handling and the regression was against what the
RFC document (so it was documented), but again, it is not important to
understand who is the author of the mistake: if someone do things is for
sure more probable that he also does mistakes. Who does nothing does not
mistake too.
The 3 test failing in MessageWriteToTest are simply failing because their
expected result is probably bad from an RFC compliance point of view.
if the expected result is wrong then it should be fixed. if the
expected result is right then the code has regressed and should be
fixed.
Expected result expected non encoded spaces.
There was no encoding support in previous mime4j (BUG: MIME4J-59) so the
code was not used there.
If we fix MIME4J-59 but we don't fix MIME4J-62 then we have to change
the expected result.
Furthermore even if we change the expected result there is currently an
issue with a CRLF added to the end of that part. This is another issue
that should be investigated to make the test suite pass.
I don't think this can be considered a regression (MIME4J-62), anyway:
this bug has been created by a much bigger bug. Previously it was
working because of the bug, and it was a concidence because it only
worked because the encoded text has no char to be escaped by the QP
algorythm.
MIME4J-59 instead is a regression.
If you think it is bad to have this failure then a fix for this is really
easy: remove the 4 msg files about boundaries and remove the 3
MessageWriteToTest failing tests. IMHO this would be bad because it simply
means hiding existing bugs, but I'm happy with any solution make you less
disappointed and more happy in the collaboration.
these bugs reported effected only the DOM API. adding tests which are
known to fail is bad for collaborators: this actions means stops
progress being made in other parts of the library.
Do whatever you like to keep collaborating. Do you need to remove any
test? Do that. Do you need to revert every commit done in the last 10
days: do that.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
