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.
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.
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.
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.
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.
Almost always they are method extensions which originally belonged to some package but where posted with other fixes.
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 ;-)
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.
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.
Cheers, - Andreas