On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison <t.p.elli...@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.
