update stream policy
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
More information about the Squeak-dev