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
|