harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk: modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java support/src/test/java/tests/resources/hyts_flushed.jar
Date Tue, 24 Nov 2009 02:04:52 GMT
On Mon, Nov 23, 2009 at 4:40 PM, Jesse Wilson <jessewilson@google.com> wrote:
> On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> On 23/Nov/2009 20:27, Jesse Wilson wrote:
>> > My bad for committing during the code freeze.
>> So you're going to rollback, esp. so we don't exclude all the other
>> tests in that type?
> I can certainly rollback the changes to the exclude.common file.
>> > Does it make sense to limit test changes during the code freeze? I don't
>> see
>> > any benefit.
>> We ensure that the tests pass and we ship the tests as part of our
>> Milestone deliveries.  The benefit of including them in the code freeze
>> is that we are not trying to hit a moving target and/or introducing new
>> bugs (i.e. the same reasons the implementation code stays frozen during
>> final test/release).
> It's dysfunctional to not checkin a test just because we don't currently
> pass it. If anything, we need a better mechanism to manage which failures we
> have. My personal preference is to just let them fail, and to watch Hudson
> for unexpected failures. Suppressing a test as it gets added to avoid seeing
> red in Hudson is bogus: our implementation is not perfect and our tools
> should relay that back to us.

Let's separate the two issues here -
* excluding failing tests - i'd agree that our current exclusion
approach isn't optimal - how can we make it better?
* extent of code freeze - should all commits be stopped? i'd suggest
that we consider for the next milestone, use branching and freeze that

View raw message