I believe that Monticello needs to be in Basic for the reasons which 
Daniel states below.  (Monticello should be trackable as an in-image 
package, as Goran preferred.)

In my earlier message I was probably stretching things a bit to say 
that there was "agreement" that Monticello should go in 3.8, but there 
wasn't widespread disagreement. ;)  Sometimes you need to say that 
something will likely be going in before you get the real arguments 
against the idea. ;)

Awhile ago, I remember one argument against including MC was that the 
base system should be agnostic regarding versioning systems (and 
changeset-like formats), and that adding something like this tends to 
infect the rest of the system so that everything is dependent on it.  I 
only partly agree with this.  I don't think the system should be any 
more dependent on MC than it is dependent on ChangeSets, for example.  
E.g. if something like Browser is inappropriately dependent on 
ChangeSet, it should not be dependent on MC either.  But I sort of 
think of MC as a better alternative to ChangeSets (with versioning), 
and it's okay for parts of the base system such as the update stream to 
rely on it, since we can get big benefits from it.

- Doug


On Wednesday, September 15, 2004, at 05:20 AM, 
danielv at tx.technion.ac.il wrote:

> [including MC in the image]
> Bert Freudenberg <bert at impara.de> wrote:
>> I assume you're speaking about the full image, right? We agreed 
>> earlier
>> on that no packaging system should go into the base image, but only 
>> the
>> infrastructure necessary to build one, in particular PackageInfo. I
>> agree it should make it into the full image which has all sorts of
>> developer tools.
>
> I believe that in the current situation, MC should be in Basic. In
> short, the reason is that Basic should include  exactly the set of 
> tools
> that are needed to improve Basic
> (http://minnow.cc.gatech.edu/squeak/3413). Do we agree on this?
>
> If so, the consider that IMO we are nearing a point at which many
> maintainers of Squeak stuff,  including Basic, will have the MC be as
> much a part of their development process as, say, the MessageNames
>  tool, and much more so than, say, the hierarchy browser.
>
> Further than that, it is a tool that could both accelerate the rate of
> change of Squeak and allow quite separate development groups to share
> code more easily. I think that's becoming more and more important - for
> example, it might make it reasonable for Squeak to integrate Squeakland
> changes (and vice versa?) immediately, instead of waiting for a
> slowdown, simply because it lowers the costs of conflict detection.
>
> Also, there's the matter of integrating MC with the update stream, for
> which Avi explained some specific options. I consider this a 
> medium-term
> goal (say a year). But the immediate benefits to including MC are not
> dependant on the timing or concensus on that goal.
>
> What do you think?
>
> Daniel Vainsencher
>