7 Oct
2007
7 Oct
'07
8:49 a.m.
2007/10/7, Jeff Garland <jeff@crystalclearsoftware.com>:
Gennadiy Rozental wrote:
Additionally it's important to split new failures from regression. New failures we just mark as expected on day of release and ignore. At the
Well, this doesn't quite work for me. If a new library can't pass tests on the 'primary platform list' then it needs to be removed from the release because it's not ready.
The definition of "New Failure" might be problematic. E.g. If a test is added in 1.35, due to a bug found (and not fixed) in 1.34, a new failure occurs in the test output. If functionality with poor quality is added to an old library, then the code should not be accepted, not just marked as an expected failure. /$