On Wed, 29 Jun 2005 21:41:50 -0700, "Andreas Raab" andreas.raab@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