update stream policy

ducasse ducasse at iam.unibe.ch
Sat Jan 17 20:38:20 UTC 2004


>> Hi avi
>>
>> for me this is a tradeoff between time and energy.
>> **now** the 17 January 2004, I write tests,  I review tests,... Now I 
>> do not have the time to create a new package
>> with monticello and publish it each time there is a new test coming 
>> out. Once tests have reviewed and approved there is normally
>> **no** conflicts. So harevsting them is simple.
>>
>> So if you provide a solution that in one click I can say add this 
>> test to this package and publish (like I could do it in VW with 
>> Store)
>> then I would use it. It should work in alpha in basic because this is 
>> with such an image that I'm reviewing code.
>
> If it's a tools issue, we'll fix the tools.  No problem.  Or, if you 
> just email *me* the changesets instead of the update list, I will make 
> sure there's a package on SM with them.

Ok believe me I will do it.
>
>> an important point is that for the changeNotifier roel told me that 
>> he spent much more times (around 5 times more) writing the tests that 
>> the code, so we would be silly to lost and not have them present so 
>> that people can read how to use it.
>>
>> Now the changeset systemNotifier are blocked in the update stream 
>> because they contain tests!!! Coooooollllll
>
> Is that true?  Can you point me to the email where someone said that 
> that changeset couldn't go in without tests?  Because that to me is a 
> completely different issue - since we're talking about a distinct 
> package with a known maintainer, and the same person is maintaining 
> the tests as the code, it doesn't make much sense to me to split them 
> up.

But I was not talking about package code with a maintainer. I was 
talking about Kernel OrderedCollection, ClassBuilder, 
SystemChangeNotifier...the core.... the deep core....

> To be clear: to me this isn't an issue of tests vs code, it's about 
> which packages go into the update stream and which don't.  I'm not the 
> slightest bit against tests, I'm against putting external packages 
> into the stream.  SystemChangeNotification may or may not need to go 
> into the stream, but whatever happens to it might as well include its 
> tests IMO.

SystemChangeNotification is ****core**** =>  compiler related, changes 
set, changeslogs....





More information about the Squeak-dev mailing list