harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
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 Mon, 23 Nov 2009 22:40:10 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message