how do we proceed for packages?

[Doug Way]

On Monday, April 4, 2005, at 02:18 AM, stéphane ducasse wrote:

> 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.

Ok, just treating it as a Full package would probably work, then, to 
get it more heavily tested/used.

- Doug


> 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
>>
>>
>