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

Alfonso Guerra hupernikon at gmail.com
Tue Dec 7 16:18:00 UTC 2004


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