On Mon, Nov 23, 2009 at 4:40 PM, Jesse Wilson <[email protected]> wrote: > On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison <[email protected]> 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 code.
