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

[Doug Way]

On Wed, 29 Jun 2005 21:41:50 -0700, "Andreas Raab" <andreas.raab at gmx.de>
said:
> Hi -
> 
> Some more comments:
> >>> 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.
> 
> Depends on whether you wanted to have the system fully packagized or 
> not. This is a key question - I have no interest whatsover in another 
> "partially packaged" system. We have this already.

Agreed 100%... I think we all want a fully packagized system, where
every single method in the system belongs to a package.  (And
preferably, every method belongs to exactly one package, which means the
Basic configuration of packages has no overrides, if possible.)

> If you *are* interested in a fully packagized system then you need to 
> make sure you know what every last line of code belongs to. The doIt 
> does that by touching every method in the system and therefore pointing 
> out (!) places that need to be fixed.
> 
> That's what this doIt is good for - it's NOT intended to perform proper 
> packagizing it is intended to show which parts of the system are not 
> included in your current package set and therefore need to be dealt with.

Actually, we are in better shape than I originally thought.  There were
a dozen or so extra MC packages that showed up after I executed the DoIt
(e.g. "Connectors", "Flexiblevocabularies", "Refactory", etc).  However,
when browsing each of these packages, they have no code, they just show
an empty list of *Extensions and nothing else.

So, my guess is that these were perhaps generated by the DoIt from some
extra extension method categories (e.g. "*Connectors") which didn't have
any methods in them.  Ah, I see a fresh 3.8-6665-basic image has a
"*flexiblevocabularies-viewer" method category on Object, which the
Reorg cs doesn't do anything with, so that's where they come from...
shouldn't be hard to clean that up.

Well, there is one stray package which did have some code in it after I
ran the DoIt.  A package called "UserObjects" has three classes,
CardPlayer55, CardPlayer57, and Player56.  Looks like some Etoys
prototype classes which don't need to be there.  There are no instances
of these classes in the 6665-basic image, so I could just add an update
cs which deletes them, and deletes the UserObjects class category.

> Since I did the work a while ago it is quite possible that later changes 
> have done some modifications that I was unaware about when I did the 
> work. I suggest you just reclassify these classes/methods too so that 
> you have a fully packagized system.

As far as "later changes" go, there are actually only two new updates in
3.8 since your iSqueak Packages image was created, 6663 and 6664.  Both
of these updates just change a few existing methods, they don't add or
reorganize anything.  So your Reorg changeset looks like it should be
fine as-is, except for the small cleanups I noted above.

> > 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.
> 
> The doIt "sort of" does this but *not* properly. To do it properly you 
> want both, a repository that the package resides on and a version of the 
> package. Here is how to do this:
> 
> a) Send out the Reorg.cs just to get things in order for people out 
> there (this includes any additional modifications that need to be made)
> b) Do whatever is necessary to get Monticello/MCConfs to the people out 
> there (e.g., put them into the update stream or so)
> c) Post versions to the 3.9 repository that include all packages which 
> should then be in a basic image
> d) Post a configuration that people out there get via update stream
> 
> If you do this, here is what will happen for a 3.9 user:
> * They get the ReOrg.cs
> * They a configuration map
> * This will force them to download the versions from the repository
> * Since the repository version will be equivalent to what is in the 
> system, no changes will be made
> 
> In other words, the above is a recipe to get the packages to the users 
> at the expense of having to download all of these packages from the 
> repository - which will take some time but it also means that (for once 
> ;-) you know that people have precisely the versions that are in the 
> repository.

Yeah, that sounds like the way to go, then.

I can put up a big warning dialog before this update, telling people
that they should strongly consider just getting a replacement 3.9alpha
image from http://ftp.squeak.org/xxx, noting that proceeding with the
big package-installing update WILL take longer than downloading a
brand-new image.  But if they're a glutton for punishment, they can
proceed. :)

> ...
> >>> 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.
> 
> See above. The only issue is that everyone will have to download the 
> packages so you guys better get that server in shape ;-)

Hopefully with the big warning message, not too many crazy folks will do
the big package install. :)

> > ...
> > 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.
> 
> No! Please, no! Not "as if" - make it the real thing! What is the 
> problem with just downloading the package and installing it? If people 
> don't want to wait they can always just grab a preloaded image.

Yes, sounds good to me, I wasn't looking forward to "faking" this
ancestry.

I'll see if I can get these new updates added to the 3.9alpha stream
tonight.

- Doug