Hi Eric and all!

Eric Scharff <Eric.Scharff at Colorado.EDU> wrote:
[SNIP]
> I don't know if I can speak for other developers, but my general strategy
> is to:
> 
> 1. Do work that I want to be stable only in the current stable release.
>    This involves the bulk of my research work, because I have enough
>    trouble tracking down my own bugs without encountering bugs of
>    others. :)
> 2. Try to play with the current experimental release as often as possible,
>    but feel overwhelmed sometimes when things change.
> 3. Do "quantum leap" ports of old stuff to the newest stable release
>    when it comes out.  Normally that hasn't been too bad, occasionally
>    things break in nasty ways.

Sounds like the approach that I think many use.

> So I don't see stable releases as dead, nor have I encountered too many
> nasty bugs in them that get fixed in later releases.  They may be extinct
> but stable. :)

Same feeling here.

> For selfish reasons, I prefer when people have packages that file into
> stable releases and don't care as much on intermediate ones.  I wish I
> could spend more time on the bleeding edge release, but the reality is
> that my users tend not to be forgiving when my systems crash, so I avoid
> it.

Same here too. Which of course also is a slight problem for 3.3 since it
doesn't get the attention it could use - but I think it will get that
when it has accumulated enough new stuff that people want to use.

> I would therefore be thrilled (and, indeed, would use) a package system
> someone built on top of 3.2 so that one need not be at the bleeding edge
> to use stuff.  However, I appreciate the pain of package maintainers who

That is actually what we are doing right now with the SqueakMap stuff,
even though it is in 90% also meant for 3.3 and beyound.

> have to maintain multiple versions and keep them more-or-less in sync.
> 
> I still fail to comprehend the true power of the package system, perhaps
> because of the lack of tools. Is it too naive for someone to look at a

The Modules system in 3.3 I assume you mean? Yes, it is powerful and yes
it can be a bit tricky to grasp.
But it's probably a tool-thing - Andreas and others have made some slick
tools that I think will make all the difference - just let it mature.

> dynamic package system now and port it to later releases (SCAN? The fine
> SqueakMap work?)

SqueakMap is very close to go into the 3.2 update stream! Daniel
Vainsencher, me, Doug Way, Scott Wallace and others are cooperating on
it and we intend to get it in there in time for OOPSLA. :-) Regarding
coding it's me and Daniel sofar.

It has been explained a few times on the list but here is another short
run-through:

1. SqueakMap is a "map" of packages for Squeak. There is a master map
running currently on marvin.bluefish.se (my dev machine) and you can see
what it contains now at:
http://marvin.bluefish.se:8000/sm
2. SqueakMap is a catalog only - it wants to be a friend of all possible
kinds of repositories in order to be able to act as the 100% preferred
way of publishing Squeak code. This is very intentional.
3. SqueakMap also holds registrations for "Modules repositories". This
acts like an mtab (Unix lingo) for the global Modules system. Not
relevant for 3.2.
4. The map can synchronize itself using simple HTTP requests using a
very efficient protocol. This is the cool part - the map will be
downloaded to the client machine and fully accessible there without any
Internet traffic. And it is updated incrementally so even with a modem
it will be a fast operation.
5. We insert the domain model code (the map itself) and a mini UI called
the miniloader (written by Daniel Vainsencher) into the 3.2
updatestream.
6. When people eventually update a new tool will pop up under "open...".
This loader will synch with the master map over HTTP whenever it's
opened and offer a flat list of available packages. It has "smarts" for
downloading and installing and keeping track of version numbers of
packages so that it can detect if a newer package exists. Essentially
this boild down to a single "click" to get a new tool/package into your
image!
7. A few notes:
	- Currently it handles .cs, .st and .gz of those. We will probably add
a .zip format too for more complex packages consisting of several files.
But in the end it relies on plain-old "file in" which is a
non-reversible process. This means that we have no "uninstall" and that
"upgrade" can not be guaranteed to work unless the package maintainer
makes sure it does (by prepping and testing the .cs so that it works)
	- Adding and changing registrations in SqueakMap can currenly only be
done through the web. That will of course be fixed later.

And as always, just ask if you want more info. When SqueakMap enters 3.2
we will of course add pages to minnow explaining it and also add some
form of text popup in 3.2 that explains how this works.

And yeah, almost forgot - please try out SqueakMap and help me with
improving the code! We think SqueakMap will be a real boost to the
Squeak as a first (rather large) step towards a distributed system for
packages - we have already identified a ton of very nice features that
can be layered on top of this.

But remember - SqueakMap is not an alternative to Modules - it is a
complement. But a very good complement and it will also make
"lightweight packages" a reality in plain old 3.2 (and older if someone
helps me with porting it down).


> As for 3.2 fixes, I'd be happy to volunteer to comb 3.2 changes for things
> that people feel are 3.2 bugs.  It's a good idea.  And although I haven't
> run into them yet, maybe I will in the future.
>
> -Eric

Go for it.

regards, Göran