On Saturday, August 14, 2004, at 02:33 AM, stéphane ducasse wrote:

> Hi guys
>
> For me any process the people working to make squeak better and safer 
> is ok. I think that enabling experts to lose less time is important.  
> After we can always set up some internal or pair coding when fixing 
> the kernel (I like to have more eyes over my shoulder because I can 
> simply mess up).
>
> Now I would like to add that having a **REAL** campaign for tests is 
> needed else statements such as
>> - Anyone committing (broadcasting) to the update stream has to run 
>> SUnit tests. (which take a couple minutes).
> makes me really laugh considering the kinds of bugs we could get with 
> the current tests we have.

Yes, but perhaps the best campaign for getting good tests would be 
forcing reliance on the tests.  If we went with the proposal of having 
just one update stream which multiple committers can post to, but they 
all have to run tests, then the tests would probably start improving 
more quickly than they are now.  At least, there would probably be some 
good functional tests added.  (E.g. If [the ability to open a window in 
MVC] is a typical thing which is broken by bad updates, someone would 
add a test for opening a window in MVC, and then it would no longer be 
a problem.)

Running tests before committing updates doesn't seem like too big a 
deal to me, since I've worked on projects where this was standard 
procedure.  Especially with Squeak, where one person would probably not 
post updates very often (maybe once or twice a week at most), running 
tests doesn't seem like much of a burden.  You can run into some 
problems, such as the tests growing into a huge suite which take 15 
minutes to run, but then this is usually caused by a few tests which 
are unneccesarily slow, and they can be sped up/fixed.  (E.g. right now 
the PNG tests take a really long time for some reason... but most 
typical unit tests are usually very fast.)

- Doug