how do we proceed for packages?

[stéphane ducasse]

Hi doug

for now I think that OB should not be put in basic but we should give a 
strong signal
and have it in 3.9 so that people test it and start to improve it. I 
think that managing it
with Monticello is the best.
So we should have MC in basic so that we can script it and load OB and 
other.
My point is that for update stream if we do not want to rely on 
mulitple servers (squeaksource)...
we have push the code in the stream but this is not really practical.

So may be we should really go in package mode. :)

Stef


On 4 avr. 05, at 5:48, Doug Way wrote:

>
> On Mar 30, 2005, at 7:00 AM, stéphane ducasse wrote:
>
>> I would like to know how we can push some packages like omnibrowser 
>> in 3.9
>> I think that this is important that omnibrowser gets used by people 
>> because
>> it is a bit sluggish right now and only pushing it in the stream can 
>> make that it gets
>> improved by the pressure of users.
>>
>> So what are the practices?
>
> Well, this is the right place to ask. ;)
>
> In this case, we are talking about adding a package to Basic.  The 
> Package team should be discussing the nuts and bolts of how a package 
> is defined within the Basic image.  (Basically, via PackageInfo 
> w/enhancements.)  And there is general agreement that OmniBrowser 
> should go into Basic so that it can eventually replace Browser.
>
> Okay, I think I see what you're getting at... The big question is if 
> it's added to Basic, via the update stream, should the master copy 
> still be on SqueakMap (maintained there), or should the master copy be 
> in the image (maintained via the update stream)?  Sigh.  This is a 
> hard problem that hasn't really been resolved, I'd say.  For Full 
> packages, it's easy enough to just remove them from the Basic image 
> and keep them 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.)
>
> 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. :)
>
> 3. Do not add it to the Basic image.  (Which will probably mean it 
> will never effectively replace Browser.)
>
> 4. Wait for some sort of magical dependency scheme to come around to 
> solve these problems... ;)
>
> Maybe once the image is partitioned into packages (which are not 
> removed from the image), and better tools are developed for handling 
> these packages, it may become more obvious how to handle this...
>
> - Doug
>
>