3.6 Full release testing (was Re: [BUG]? Upgrade to full image

Martin Wirblat sql.mawi at t-link.de
Thu Aug 21 11:18:06 UTC 2003


Hi Andreas,

>
>Hi Martin,
>
>> >> And if it is not in the image, it is not being used and so it 
>> >> will not get tested. That would be a big change in practice.

This was merely a play with words to show a different logic by 
rearranging what Göran said, standalone it looks a bit funny. 

If you want to split up testing and developing, then yes there are at 
least 2 reasons for supporting Full in the same way the monolithic 
image got supported. From what I saw on the mail list, there is really 
the effect of what I called 'statistical testing' - sometimes even 
inadvertently testing by playing around. There were quite some bugs 
and problems found this way. To have some 'statistical' testers it 
should be made as easy as possible to have an actual alpha/beta/gamma 
Full image. 

And yes, your description why "general" Squeak development should be 
done in Full shows exactly what I think. We cannot expect to have a 
Full release when we work in and support only part of Full. 

In short words, any fragmentation of the 'scope' of procedures will 
make things more difficult than with the old monolithic image. 
Generally we should aim to mimic procedures regarding Full as if it 
were the monolithic image. Just a modularized one. 


Regards
Martin

"Andreas Raab" <andreas.raab at gmx.de> wrote on 21.08.2003 00:46:27:
>
>Hi Martin,
>
>> >> And if it is not in the image, it is not being used and so it 
>> >> will not get tested. That would be a big change in practice.
>
>I think your argumentation is slightly off here. Let me try to point 
>out why I think having "full" images and update streams is 
>advantageous for development: It is awareness and ease of change. 
>What this means is that if a package is present you are immediately 
>aware of potential problems with that package when you modify 
>something. When it is at SM you don't. So you change things, and then 
>some package maintainer has to (more or less) reverse engineer your 
>changes in order to figure out how things ought to work according to 
>your new rules. 
>
>An excellent illustration for this problem is Anthony's rework of the 
>EH stuff. In its original form, it contained a number of fixes to 
>various exception classes, including TestFailure. The fixes for 
>TestFailure, due to being part of the (at that time non-basic) SUnit 
>package were removed before the changes went into the update stream. 
>As of today, SUnit is still broken in exactly these places. It is not 
>that Anthony didn't fix them (he did) it is that the mere act of 
>separating "cause and cure" of a problem introduces a significant 
>additional barrier. 
>
>That is the real problem we're talking about - the difficulties to 
>detect dependencies in external code, the disproportional amount it 
>takes someone to fix a problem that someone else introduced, the 
>(very realistic) chance that a package maintainer overlooks a problem 
>that is introduced by a change done by or in some other package, the 
>inability for someone who does a change to ensure that even required 
>fixes really make it into the appropriate packages. Note that for the 
>person doing the change in the first place, these issues are 
>typically trivial to fix (again, see the TestFailure example, and the 
>same can be said about things like KCP or MCP) but it is very hard to 
>find and fix them if you are not the person who has done those 
>changes in the first place. 
>
>By the end of the day, this is the same line of argumentation that 
>has been made various times about "code rot" when certain changes 
>don't get in the image soon. It is caused by people (note: people not 
>tools!) simply not being aware about dependencies, it is caused by 
>even if you try your best and fix every last place it doesn't mean 
>you can ensure that your fixes reach the intended audience.
>
>Of course, that is noones fault - it is a mere matter of fact. That's 
>why I think that it makes sense for all "general" Squeak development 
>to use full (or more) instead of basic images. Not because of testing 
>(since here I agree that presence of a package has very little to do 
>with it) but rather for being able to rapidly detect and cure 
>problems you have introduced during development.
>
>Cheers,
>  - Andreas




More information about the Squeak-dev mailing list