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). 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. Thanks, Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
