how do we proceed for packages?

[Doug Way]

Sorry, I see that I somehow missed responding to this particular post...

On Mon, 4 Apr 2005 11:41:13 +0200 , goran.krampe at bluefish.se said:
> Hi fellas!
> 
> Doug Way <dway at mailcan.com> wrote:
> [SNIP]
> > on SqueakMap and maintain them there.  But with Basic packages, they 
> > really need to be "in" the image.  (Yes, we'll also have a Minimal 
> > image one day, but the update stream really needs to follow Basic.)
> 
> May I ask why they need to be "in" the image? (this is not irony or
> anything like that, I just would like to understand the perceived
> problem better)

I probably overstated the problem... I guess they don't *really* need to
be in the image.  But for some lower-level packages, when you need to
worry about things like having DoIts execute in a certain order, it
might be simpler to manage those via the udpate stream.

My brain is hurting a bit trying to remember all the issues right now.
:)  I think I was also thinking about changes which cross-cut a bunch of
packages, that those are easier to deal with if you manage all those
packages via the update stream.  (Although in theory if things are
properly detangled, you eventually shouldn't have too many of those
types of changes.)

But there's some new discussion on the packages list about trying to
manage everything with MC, along with the update stream, which sounds
like a good balance.

> > So, the options are something like this:
> > 
> > 1. Add OmniBrowser to the Basic image via the update stream, and 
> > maintain it in the image via the update stream from then on. (e.g. 
> > Colin would have access to update it via the update stream)  But still 
> > keep it clearly defined as a PI package.
> > 
> > 2. Add OmniBrowser to the Basic image via the update stream, but still 
> > maintain the master copy on SqueakMap.  When significant changes are 
> > made, a new version is added to the update stream from SM.  This is 
> > kind of what we're doing with the SqueakMap package itself.  It's kind 
> > of clunky... I don't like this. :)
> 
> Why is it clunky?

I guess mostly it was that we had kind of a mix of things maintained via
the update stream vs packages... it's probably best to go all one way or
the other.  The MC scheme sounds good in that respect.

(I suppose you could have had everything in the base image maintained in
SM packages, but you wouldn't want to support any non-MC packages in the
base image anyway, so it's probably best just to use MC directly for
that, with its more integrated source code tools.  E.g. with MC you can
determine which package a bit of code belongs to, with SM you cannot. 
SM is still great for managing the larger universe of Squeak code
outside of the base image, though. :) )

- Doug