> "Known bugs still to be fixed" should be a separate package that you
> can load if you are going to fix the bugs.  There should not be any
> SUnit tests like that in a released, stable image.  Not even in an
> alpha or a beta image.
This might be an ideal, but I don't think that it is practical, since an 
individual bug to fix test may well (should) exist in the context of the 
other tests for that package/set of functionality. Making a separate 
change-set or package for such a test just seems too much. Once the fix 
is made then the  individual bug-test method  from the 
separate-bugs-to-fix-package would then have to be integrated etc etc.

I would prefer to have the full information available to me in order to 
assess the state of an image, whether declared stable or not. For me the 
50 or so tests that fail in the 3.9 image would be ok if they were in a 
"tests we expect to fail" category.

With the scheme I propose, you select the "tests for release 3.10" 
category of tests, and hit run, if all the tests pass then great. The 
existence of miscellaneous snippets of code in the image that are not 
part of that category is simply an ignorable artefact for the purpose of 
validating that release. Those snippets might be named #bugtestMyBug or 
#release39Test or #extraLongTest.

my 2p

Keith



	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html