Chris C., what mailing list was this conversation orginally sent to? Looks like all your headers were clipped (as they always are!). This was sent two days ago but I'm only now seeing it only because Dave forwarded it to the proper lists..?
Anyway, we need to talk!
On Wed, Apr 9, 2014 at 11:31 AM, David T. Lewis lewis@mail.msen.com wrote:
Chris, I think you are making some rather questionable assumptions here, not the least of which is that somebody else is going to take care of migration. "Somebody else" means nobody.
We have a very real problem related to migrating critical community resources from the old infrastructure to the new infrastructure. We do not have enough resources (people, time, knowledge) to keep the old stuff going forever, so we really do need to get on with the process of completing the migrations. SqueakMap is one of the critical services that needs to move.
It might or might not be a good thing to write a new and better SqueakMap server application, but writing a new application and waiting for somebody else to come along and do the migration does not sound very helpful.
Dave
SqueakMap uses Monticello to load packages
No, it doesn't. SqueakMap knows nothing about Monticello. SM uses plain Smalltalk .st scripts. That's where its flexibility and power comes from. Currently, many, but not all, of those .st scripts invoke Monticello loads because that's our current SCM tool.
Yea, the changes I'm making to a new version of SqueakMap will heavily favour this. The idea is that SqueakMap is not a repository (no saving code on box4) and code should be in a SqueakSource repository somewhere. At bottom, the map is a file that stores URLs. So if you want to store an alternate file format (i.e. sar), then you could put the file on a server of your own. Then you'd put the URL into the map as the release. But I think that the days of storing code on a Squeak box, which is then served by SqueakMap will not be continued in the migration to box4.
That, of course, raises questions. What to do with all those (85% empty) directories in /squeakmap/sm/cache and /squeakmap/sm/accounts? 15% of those contain code of some sort. My attitude is that I may be working on a new version of SqueakMap server, but that I'm not responsible for migration. The new map will be an empty file. It'll only have the apps that I've put into it. Empty.
I figure let people migrate if they want. If not, zip the whole thing and store it somewhere.
Well, that certainly defeats the whole purpose of a Catalog. I certainly won't be using the "new" one if this is your intent.
Chris C., please DO NOT rip down any more existing Squeak services. You need to coordinate such drastic resource changes with the community.
The only problem I have with SqueakMap is that for packages like TwosComplement or PunchedCards on SqueakMap, which run on more or less any version of Squeak, I am expected to remember to update those packages on SqueakMap every time someone releases a new Squeak version. This is annoying and eventually I might run out of patience and forget to do it.
This is interesting. This speaks to me about a catch-22 involving categories in SqueakMap, which is one of my least favourite features. I think your old code is always available, but the labels make it invisible. I think Chris Muller uses the filters (based on categories) liberally with each release. The reasoning is sound: only show packages that have been labelled as working with the latest release. The reason for that is to keep the hundreds of rotten packages out of sight. That's an admission that all those old packages are a problem. The catch-22 comes in, I think, when I say the new SqueakMap will be an empty file, a new map, and that all those old packages should ether be thrown away, or, at best, zipped into a glob and stored into a closet. I imagine this idea will meet with some resistance.
Chris C., clearly you have not thought this through..
The thing you need to know about the new SqueakMap is this: I'm building the tool I want to use. The Squeak community may be responsible for a legacy of SqueakMap code, but I, Chris Cunnington, am not. I will have moved things forward. If it's not far enough for people, the source will be freely available. It will be one of the first packages in the new map file, the 7000 series, (as opposed to the 5000 series). You'll be able to download the SMServer code from SqueakMap.
Chris Cunnington, I suggest you take this attitude and your work over to chriscunnington.com, where you are free to create a new empty SqueakMap and invite people to use it. If you can get community excited and using it, then the transition will take care of itself.
I repeat, Chris, do NOT do to SqueakMap what you did to the old squeak.org website. You MUST involve the community and win their support first.