[Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff)

[goran.krampe at bluefish.se]

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> goran.krampe at bluefish.se wrote:
> > Or putting it another way - making a competitor to SM or DVS would be in
> > many ways counterproductive since these tools in some ways work their
> > magic by turning into de facto standards for the community. Much better
> > to cooperate on them. :-)
> I disagree in general - alternative solutions to the problem DVS solves,
> for example, don't hurt the community, because their functionality is
> more important than the synergy of sharing the same format. This is

Well, I agree. Nevertheless, the more people that use one format the
more incentive to make that a good format. But whatever.

> because the different formats do not add significant issues, because SM
[SNIP]  
> > And that is btw one of the reasons I really want opinions on SM. Since a
> > few important issues were reaised on the list recently I am in the
> > process of writing down how SM1.1 will work on:
> It's been a couple of months since the last time I said this, so I
> consider it borderline-polite-nagging ;-). 

It's ok, I know I have talked about SM1.1 for a long time and haven't
delivered yet. I can't say anything else than that I am trying but that
a small thing called "life" keeps me pretty busy. I do have more time
now though than before.

> IMO, nothing matters as much as that you release something as soon as
> possible that supports package releases. 
> - Details of distribution of the DB is unimportant. 
> - UUIDs vs. names is unimportant. 
> - Caching is unimportant. 
> 
> Why? because releases in SM allow dependencies to be handled in various
> intelligent ways, which would save people like Stephan from inventing
> their own schemes that are non-scalable simply because versions are not
> supported. Such a release would let loose the next "avalanche" of
> progress in the package handling aspects of Squeak. Also, while 3.6
> release is pretty far away, we do need to start seeing how we actually
> handle releases in and after it, and to do that we need SM 1.1.
> 
> So please do whatever you can to release asap, we need SM1.1 now! :-)

I know. I am not sure though that I agree with the three bullets above.
The first one I agree with. The second one is... I agree, not
*important* - but harder to change the longer we go. My current thought
is to "prepare" a bit by some very small adjustments and simply keep
doing things as they are. So I am keeping UUIDs for SM1.1 but preparing
for 1.2. In other words - no effort lost on that issue at this point,
don't worry.

Caching is not that unimportant because I think it is a key mechanism
for the distribution of 3.6. I want people to be able to easily download
a minimal/basic image and to be able to build "full" themselves. So I
actually think PackageReleases (+ the little simple mechanism to add
meta info to packages/releases which I call SMResources) and the cache
are the key features of SM1.1. I will most probably only go for those -
unless some very easy things pop up along the way that seem good.

But in general I agree with you Daniel. :-)

regards, Göran