Hi all!

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Brian,
> 
> > I see SM as a system containing Community contributed 
> > software, where the individual maintainers post new updates
> > to those discrete packages, and I as a user can choose
> > whether to update a particular package or not. 
> 
> Yes. And wouldn't it be appropriate to have the same ability when you want
> to update your system to the next version?

Yes, the important thing to notice here is that SM is not only for
"community contributed" software but is actually going to keep track of
the packages of official Squeak too.
 
> > I see the update stream as dealing with "Core" Squeak code, 
> > bug fixes, enhancements, etc, as fundamentally different the SM
> 
> Fundamentally different? Where? Both are mechanisms for distributing code
> and whether a package contains a self-contained set of changes or not is
> really up to the maintainer. For example, SmaCC requires the RB parse nodes,
> Jacaranda requires Connectors. Where's the difference?

Yes, principally no difference. The update stream is a stream of deltas
and not package aware today.
SM isn't primarily for deltas but can of course if needed. But I did
want to introduce the concept of update streams *per package* somehow.
On the other hand - perhaps it would be better to use Monticello as an
"update stream". Those packages that do have active maintainers could
then serve "the hottest" using Monticello. (similar to how the rest of
the world uses CVS for "the hottest").
 
> > I understand this line of reasoning, but I think this will 
> > lead to confusion on the part of users, especially new users...
> 
> Most of the confusion of new users come from obscure UIs...

I don't think it will be confusing if we make good tools. Debian is
again a good example - they have a tremendously complex and advanced
system but users don't need to know - they just "apt-get install
blabla". :-)

> > and when the dependency code is part of the mainstream SM,
> > and I want to load Jacaranda, then it will load 
> > Ned's connectors and possibly.... say, bug fixes to Squeak, 
> > so it revs it 3.5.3 or something?
> 
> If you're okay with pulling in Connectors why is it so problematic to you to
> pull in a version update? In both cases you get "more than you want" and I
> would claim that in both cases you should therefore get an information about
> what is going on. For example:
> 
> Jacaranda vX.Y requires the following packages to be present:
> 	* Connector (vX.Y)
> 	* SqueakUpdate (vX.Y)
> Do you want to load these?
> 
> The system tells you what it is going to do and it's at your disposal to
> take it or leave it. To me, that's clearly an advantage about not being able
> to load Jacaranda at all, don't you think?

Yes, and this is how I am envisioning SM when package releases and
dependencies are in place.
It will even be able to help the user resolve potential conflicts.

> > I would like to see (at least I think I would at this 
> > point).. putting *all* bugfix type updated into the
> > update stream... so if Magma has a bugfix posted 
> > to it, when I choose "Get code updates" from the World menu, 
> > it not only fixes my core Squeak bugs, but any installed
> > packages I have as well (but not upgrading packages to new
> > versions!)
> 
> But that's entirely unrelated to what I was saying. One is the issue of
> hosting Squeak version updates at SquakMap (which I was talking about) and
> the other is the ability to have update streams for each package (what you
> are talking about).

Right. I agree that we could host minor (as the z in x.y.z) release
deltas on SM.
But what does it give us? Sure, easy to move from 3.5 to 3.5.1 in one
big step.

Would we use this together with the stream? I mean, how would people
otherwise tap into the incremental fixes etc? It would be interesting to
hear a bit more about how you envision it Andreas.

regards, Göran