On Mon, Jul 21, 2008 at 4:06 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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.
thanks >>>> 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 ;-) unless mime4j is build and integration regularly with JAMES, it's easy for regressions in mime4j to break JAMES >>>>> 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). thanks >>> 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. i'm taking a look at it now. the problem with having lots of failing tests around is that it makes regression testing harder. >>> 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. it's looks a bit more complex: the codec was intentionally designed for use only with non-textual attachments. (IIRC there is different guideance for that.) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
