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.

For me the most important point is that test should be in basic image, 
full image and alpha. If we consider tests as documentation
why don't we bundle them together. Why do not we also put class comment 
in a separate package.
This is an education point. I will not repeat again what I say about 
that. Everybody can read any XP book or other stuff to see the value of 
tests.

>
> Markus, Stef, do you have objections to that?  Guides, am I correct in 
> thinking that this was the intent, moving forward?

After I have no objection on the goal, and I'm working on it. The KCP 
stuff is going in that direction. Cleaning &*^&^^* SystemDictionary or 
Utilities is not something you do just because you have nothing to do 
and I have far too much stuff to do.
So where should I sign, where so that I get a clean mini squeak and 
some nice load script with packages.
But where is squeak mini ckernel + nice load script and dependencies.

Avi I started to use monticello and I'm sad to see that I cannot 
express dependency between my package (lukas told me that
a solution is to have only one package, believe me I laugth a lot after 
having worked with this ugly/horrible Envy). So I sue the means I have 
now.

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


Stef

> It's not about whether the tests are in the image "by default".  It's 
> a matter of *how* the tests get added to the image, and how they get 
> maintained.
>
> Traditionally, when we add a new bunch of code to the image, we do so 
> by bundling it up into a big changeset and dumping that into the 
> update stream.  When there are changes to the code later, they get 
> posted as an ENH or a FIX, go through the approval process, and 
> finally end up in the update stream as well.  This process has a 
> number of problems:
>
> - it makes building a minimal image harder
> - it increases licensing complexity (anything put into the update 
> stream in this way is almost certainly "infected" by the Squeak-L)
> - it puts added load on the BFAV approval process, and on Doug or 
> whoever maintains the update stream
>
> The alternative way *of getting code into the image* is to put it as a 
> package on SM, preferably in an "updatable" package format like .mcz, 
> and issue a simple, small item into the update stream that loads it 
> from the map.  Any changes to the code get made to the external 
> package, and SM gets updated with the new version.  Anyone who wants 
> these changes can grab them from SM as soon as they want; eventually, 
> a new small item can be added to the update stream that loads the new 
> package version into everyone's image.
>
> My understanding was that we were going to move away from the first 
> way of doing things and towards the second, with the goal that 
> eventually most of the code in the image would be maintained as 
> external packages (*even if it was also included in whichever default 
> image people download*), rather than with the update stream.
>
> To be perfectly clear, I would propose that we institute the following 
> policy for the update stream.  The only acceptable kinds of updates 
> are:
>
> - those that make fixes to code already in the image
> - those that remove code from the image
> - those that load or update packages from SM