Hi Hannes and all!

Hannes Hirzel <hirzel at spw.unizh.ch> wrote:
> Hi
> 
> SM has been a success story so far. Just this morning I threw up a
> package loader after a long pause using Squeak and I could instantly
> load one of the 400 existing packages. This would have been unthinkable
> three years ago. Congratulations Göran and the others who helped to put
> this in place.

Thanks!
 
> As for centralization / decentralisation: SM is basically a catalogue
> and having just one instead of several is surely a great advantage.

I think so. Sure, we should strive to add the possibility of SM objects
with limited visibility (read company/organization/individual etc) but I
do not want to sacrifice the power of having ONE model/catalog.

<autotriggered rant not aimed at Hannes :) >

I repeat again what I have written a bunch of times already -
distributing/splitting a catalog over disparate unknown servers, forcing
the user to find the servers and somehow "collect" information from them
- and not knowing if there are even more servers out there somewhere
that he/she has missed.... well, it is simply a bad idea IMHO.

The only good reason for having multiple servers is the visibility
argument (the ability to have private packages etc), but I still want to
know how to get that without sacrificing tons of other good things we
have today.

</rant>

> Especially if we currently still deal with a few hundered packages and two
> hundred developers (which is encouraging though).

I think we can cope with more. The map is still quite small - and if we
move it to an incremental model (not having to download a full snapshot
every time) we should be able to handle LOTS of objects.

Note that Debian just recently added "categories" (they call them
debtags and I almost called categories "tags" too when I wrote the first
SM) and AFAIK they have more than 12000 packages in Debian proper.

> The packages themselves are in various places
> (though cached in SM AFAIK) and they have a unique ID. So it is possible

Only cached on the client at this point, though the server side cache
has been written but still sitting in my development image. The client
will first try the original URL and then falls back on the server cache
if that fails.

> to create build scripts with repeatable results which is really
> necessary for working in an environement like Squeak which is in
> constant flux.

And I can at this time, for anyone still reading, mention that I
yesterday executed two unit tests green that made the very first partial
dependency analysis. New class called SMDependencyEngine.

So dependencies are finally hitting the code! :) But since it is
currently such a hotly debated area I can't promise anything regarding
how/when/what will go into the public SM.

> And SM supports different source managment systems.  Currently
> there are 5 package formats
> http://map1.squeakfoundation.org/sm/category/93f6630c-58a6-42c5-9eb0-a43017bdf1e2

Yes, and if there are others out there that people would like to add -
just holler. IIRC someone mentioned sucking releases straight out of
StORE a while back?

> SM is a catalogue with 200 people maintaing the entries - from a
> organizsational viewpoint this is far from beeing a centralized solution.
> 
> But it works and it works fine.
> 
> Cheers
> Hannes

Cheers!

/Göran