3.9alpha update stream (was Re: source.squeakfoundation.org)

[Doug Way]

On Wednesday, June 29, 2005, at 08:20 AM, Avi Bryant wrote:

> On 6/29/05, Doug Way <dway at mailcan.com> wrote:
>
>> - Update cs #1:  Full Monticello changeset.  For now, I'm just using
>> Monticello-ar.245.mcz for this, which is the latest one in the
>> Squeak3.8-Packages iSqueak image, because we want a version that works
>> with MonticelloConfigurations.  Or can we just use one of the base
>> Monticello releases such as Monticello-avi.231 ?  (Does the Reorg cs
>> depend on a specific Monticello version?)
>
> We definitely want one of the Impara versions, for the configuration 
> support.

Ok, I'll go with the versions I mentioned for cs #1 and #2 then.

>> - Update cs #4: The partitioning DoIt cs (from http://source.impara.de
>> ->
>> Projects -> iSqueak -> wiki).
>>
>>
>> Note that after I do these steps, the list of packages in the 
>> Monticello
>> browser is somewhat different than in the Squeak3.8-Packages image, 
>> this
>> may need some cleanup?  Not sure where Connectors and some of the 
>> other
>> packages came from.  See attached screenshot.
>
> I think those come from cs #4, right?  Do we need to run that?  I'm
> not sure we want all of those automatically created packages in there.

Yes, but I thought cs #4 did all of the other PI-creation as well, so I 
assume it is necessary.  I.e. it creates the Kernel, Collections, etc 
MC packages from the class categories.  Installing MC doesn't do this, 
does it?  The Reorg cs does not do it, it only shuffles class 
categories around.

Anyway, I can go through the steps again with my image tomorrow (which 
I don't have with me at the moment), and see where these extra packages 
are coming from... I should be able to figure this out.

>> Hopefully we can do all of this cleanup through updates, so that 
>> people
>> can continue to follow the update stream from a 3.8 final image if 
>> they
>> want.  Otherwise, we'll have to just tell everyone to download a new
>> 3.9alpha partitioned image, which wouldn't be the end of the world, 
>> but
>> it'd be nice to avoid that.
>
> The other thing we'll need to generate will be a changeset that
> provides the ancestry metadata for all of the initial package
> versions, so that the MC working copies will be in the same state as
> they would have been if all the packages had been loaded from the
> repository (which will take a long time and we don't want to put
> people through if we don't have to).

Ok, that would be good.  Mm, any suggestions on how I should do this? 
:-)  Of course, most of the packages are really the "initial" package 
versions as you say, so they don't really have any "ancestry", right?  
E.g. we would have Kernel version 1.  But there may be something 
missing that I should add in any case... as if it were loaded from the 
repository, I agree.

- Doug