update stream policy

Avi Bryant avi at beta4.com
Sat Jan 17 20:04:36 UTC 2004


On Jan 17, 2004, at 11:37 AM, ducasse wrote:

> 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.

> 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.  
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.




More information about the Squeak-dev mailing list