improving the quality of the image

nicolas cellier ncellier at ifrance.com
Tue Jan 30 00:26:45 UTC 2007


stephane ducasse a écrit :
> I agree too. This was not our intention to ship 3.9 with broken tests 
> but we had to stop and nobody really stepped up to help (except one person
> but I do not remember and we tried to harvest his fixes).
> 
> Now in VW a guy in our team extended SUnitToo to support failing tests 
> and I think that this is a nice alternative.
> 
> PS: I would avoid to put code on mantis as cs but publish packages on 
> squeaksource since this is easier to deal with them.
> Create one package FailingTest and this way if someone wants to have a 
> look to fix a test he can load all of them in one shot.
> 
> 
> On 29 janv. 07, at 18:23, Bert Freudenberg wrote:
> 
>> I actually side with Ralph on this one. It is very satisfying to see 
>> the test runner turn green. With tests in the image that you cannot 
>> fix, you will never get this satisfaction.
> 

If I follow dominating logic in this thread, the process to incorporate 
a patch could be:
1) make a subclass of KnownBug instead of TestCase for the bug test.
2) write or Load a patch.
3) check non regression of all TestCase suite (green bar).
4) reject the patch or goto 2) if TestCase suite bar is red
5) check correction of targeted KnownBug
6) reject the patch or goto 2) if bug test red
7) accept the patch and move test from KnownBug to TestCase hierarchy

As you can see, you will need an image holding both KnwonBugs and 
TestCase during patch process.
In this image, KnownBugs must not turn TestCase suite bar red.
So the SUnit framework SHALL deal with this feature.

Alternative is to use two images, one for for bugfix and the other for 
non regression test, but with the risk of having images diverging.

Whatever you use, protocol or subclass or any other flag somewhere in 
the image, you just need a classification that you can change easily.

If the SUnit framework deal with this, the question raised is why should 
we remove KnownBugs from the image?
- for cosmetic reasons? (it cannot be a commercial reason: as already 
said, knowing some big company success, it's obviously not so hard to 
sell bugs)
- for cleaning reasons? having a small image... I cannot believe that 
KnwoBugs suite is as big as TestCase suite, so you gain relatively few.

Alternatively, why should we keep KnownBugs in the image?
- for encouraging people to fix them? people look more often in their 
image than in mantis don't they? Scanning the mailing list, you will see 
that a lot of people tried to make these light turn green in 3.9 
process, not always successfully that's true, some bugs are terse.

If we keep it in the image, it must be a package maintained with 
SqueakMap and Monticello so that people can share. I totally agree with 
Steph.

If we do not, we have Mantis database.
Mantis is rich but information is rather scattered...
It contains old bugs already fixed, complete and incomplete fixes, 
enhancements, feature requests and non bug.

It is not convenient enough and we need an improved way to load all 
known bugs at once. I am sure Steph and Marcus can confirm that.

However, if one wants to fix a bug, he should better keep the link on 
mantis database as it is the place to read other programmers discussion, 
bug tests and eventual (partial) fix attempts...

So this is the only thing that annoy me in Steph proposition.
How to re-concile these two forms?

It must be noted that a side effect of 3.9 red light has been that bugs 
were reported several times in mantis with several patches uncompatible 
or uncomplete...

Use an automaton with some special tags inserted in mantis comments 
processed within Squeak?
Human usable Hyperlink to mantis from within squeak?

Nicolas




More information about the Squeak-dev mailing list