QA in Squeak (was: Re: [Bug][Fix] Setting copy/paste-keypreference under Windowsdoesnot work)

Andreas Raab andreas.raab at gmx.de
Tue Dec 7 16:35:45 UTC 2004


> However, while the establishment of QA "inspectors", whose job it is
> to verify and approve any and all changes to the classes and objects
> in their areas of responsibility, you might find:

I am totally aware about these effects. However, unless we want to play
russian roulette we better think twice about whether a slowdown of the
evolution in certain areas like compiler or VM isn't advantageous to risking
the viability of Squeak as a system.

> Hasn't SUnit been incorporated into the image and various Unit Tests
> for the Classes been written? Shouldn't that be the primary barrier to
> unwarranted behavioral changes?

It would be nice if that were possible but it isn't. You see the changes had 
unit tests attached to it. But these tests didn't cover the large-scale 
implications and the places which got broken don't contain any tests for 
this behavior (and how could they - you don't write code assuming that the 
language might change under your feet or else you wouldn't even know where 
to start with your tests).

Cheers,
  - Andreas

----- Original Message ----- 
From: "Alfonso Guerra" <hupernikon at gmail.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, December 07, 2004 8:18 AM
Subject: Re: QA in Squeak (was: Re: [Bug][Fix] Setting
copy/paste-keypreference under Windowsdoesnot work)


> On Mon, 6 Dec 2004 10:55:05 -0800, Andreas Raab <andreas.raab at gmx.de>
> wrote:
>> Folks,
>>
>> Sometimes I really don't know whether to laugh or to cry when it comes to
>> the random eye-ball principle of reviewing fixes.
>>
>> Lex wrote (in an entirely unrelated thread):
>> > Anyway, I agree on the change to the last line, that #true should be
>> > true.  Doh!  Someone should do an image scan for every true, false, or
>> > nil that is in a literal array....
>>
>> The change that we're looking at here is was made in update
>> 5736nilTrueFalseInLiteralArray-avi which resulted from a discussion about
>> whether nil, true and false in literal arrays should be compiled as
>> symbols
>> or not. While I don't mind the decision being made that these should be
>> compiled to the literal objects instead of the symbols it really drives
>> me
>> crazy that not a single of the reviewers of that change to a low-level,
>> high-impact area (we're talking about Scanner here mind you; this is even
>> lower-level than a syntax change!) spent half a second to think about
>> what
>> this change means to the existing system, e.g., what might break because
>> of
>> it.
>>
>> It's not hard to find out you know - simply browsing the "senders" of
>> nil,
>> true and false and checking where they are used in the existing system
>> gives
>> you a perfect idea what parts might be affected. I will show you a few
>> here:
>>
>> ClassBuilder>>reservedNames
>> Player>>acceptableScriptNameFrom:forScriptCurrentlyNamed:
>> StandardScriptingSystem>>acceptableSlotNameFrom:forSlotCurrentlyNamed:asSlotNameIn:world:
>> ColorType>>updatingTileForTarget:partName:getter:setter:
>> DataType>>updatingTileForTarget:partName:getter:setter:
>> EToyVectorVocabulary>>eToyVectorTable
>> ExternalData>>fields
>> Win32Handle>>fields
>> X11Drawable>>fields
>> X11GC>>fields
>>
>> In other words, if you think about the implications for two seconds and
>> just
>> briefly scan over the affected places you can see that the change has a
>> good
>> chance of breaking just about THREE major parts of Squeak: Recompilation
>> of
>> all classes, eToys, FFI. And this doesn't even include the parts it
>> already
>> potentially DID break, such as everything in external packages.
>>
>> It seems to me that changes with such major implications ought to be a
>> little more carefully looked at than by just say "(et) works for me". I
>> am
>> MAJORLY pissed off that we start doing these random eye-ball reviews in
>> parts of Squeak that will affect its suitability for everyone - how
>> posting
>> a GC, or method lookup changes and have a few people who understand next
>> to
>> nothing about the VM and the implications of such a change say "works for
>> me"?
>>
>> I am *really* pissed off. I am pissed off to the point that I am
>> proposing a
>> change in the current reviewing and approval policies in a way that
>> certain
>> areas (which coincidentally include compiler and vm) can ONLY be reviewed
>> and approved by people who have shown their qualification in this area.
>> NOT
>> by Joe Blow "works for me (et)".
>>
>> Regards,
>>   - Andreas
>>
>>
>
> You have very valid concerns regarding the stability and integrity of
> the system when QA is done in a haphazard, "someone else will catch
> the error" manner.
>
> However, while the establishment of QA "inspectors", whose job it is
> to verify and approve any and all changes to the classes and objects
> in their areas of responsibility, you might find:
>
> 1. reviewing code is one of the least enjoyed aspects of development,
> even less than writing comments and documentation;
>
> 2. development on Squeak will slow as changes are channeled through
> inspectors;
>
> 3. the role of designated inspectors will be difficult to fill, and
> may often be vacant for some time;
>
> 4. the burden of verifying the effect of code changes should be the
> responsibility of the submitter, and monitored by the community as a
> whole, not on some poor slob who misses out on all the fun.
>
> Hasn't SUnit been incorporated into the image and various Unit Tests
> for the Classes been written? Shouldn't that be the primary barrier to
> unwarranted behavioral changes?
>
> -- 
> Alfonso Guerra
> Apokalypse Software Corp.
>




More information about the Squeak-dev mailing list