Bug tracking

jim benson jb at speed.net
Thu Jul 30 05:47:19 UTC 1998


Eliot & Linda wrote:

> One thing I';ve seen people do at ParcPlace is to use the system. 
> e.g.
>
> !Object methodsFor: 'error handling'!
> commentOnly
>         ^self error: 'method for comment only'
>
> bug: aMessage
>         "Change to true if you want bugs to halt execution"
>         false ifTrue:
>                 ["Change to Transcript show: ... if you want a record"
>
>                 ^self error: 'method contains bug: ', aMessage]! !
>  

[snip]

This works when you know which method contains the bug. Unfortunately,
my bugs tend to be more systemic. E.g. the cursor is not the correct
shape when it interacts with  such and such an item on the screen.
Typically, an end user describes the result of the bug and rather rudely
omits which method is causing the error,  and expects me to find the bug
and fix it !

Because I am making system level changes,  I usually end up  going on
bug hunts which generally are one hour trips deep into the inner
workings of Squeak. I rarely get to address the bug when it is first
presented, thus the bug report.

I am interested though in how this  solution scales when several people
are working on the system at once, and how you divvy up bug fixes among
a group when using this tracking method.

Thanks for the idea,

jim benson





More information about the Squeak-dev mailing list