I agree with daniel. It is really important for 3.6 to have the same 
appeal for beginners than 3.5.
As soon as we know that we can remove the packages having a full image 
is great. While loading then
is already another step. We could even have a test that remove package 
check what need to be checked (always easy to say it like that:)

Stef

On Sunday, August 17, 2003, at 06:26 PM, Daniel Vainsencher wrote:

> My opinion is known - I want to address the interaction of SM2 with the
> original plan, and our goals as I understand them.
>
> Our goals are to improve Squeak as a platform, and make it useful for
> more people. The modularization effort is one way to improve Squeak, 
> and
> the removing of packages (in a way that they can be reloaded cleanly) 
> is
> the proof of the modularity. As far as the platform goal is concerned,
> the fact that a package is reloaded after removal is of no consequence,
> as long as its maintenance happens as a package.
>
> We also have another constant goal, which is that Squeak as newbies
> percieve it be useful to more people. SM2 will make it possible to
> easily create many images using configurations of packages, which is
> what makes it possible for us to say that while we remove the packages,
> it is easy for a newbie to get one of the configurations and see a full
> system.
>
> Since SM2 is not yet online, to put up only a stripped image is to 
> forgo
> the second goal. I propose option 3 because it allows us to progress on
> both goals.
>
> As Colin says, eventually, the quality of each package will depend on
> the testing that its users decide to give it. But in the current
> situation, where the barrier to testing packages not in the image is 
> not
> yet trivial, not bringing in the Full packages for the beta means that
> we give up either on making a demonstration image, or on its quality.
>
> Daniel
>
> Doug Way <dway at riskmetrics.com> wrote:
>>
>> (Sorry, I've been out of commission for the last couple of days 
>> because
>> of the eastern-U.S. blackout.)
>>
>> Argh, this is not turning out to be a simple decision.  I guess I'd
>> like at least a little input from the Guides and community before
>> deciding, although we need to do something soon.  Say, in the next
>> couple of days.
>>
>> There are roughly 3 options to how we prepare for the 3.6 release:
>>
>> 1. The original (?) plan:  Keep the 9 removed packages out of the
>> update stream.  When we move to gamma, the current update stream image
>> becomes the "Basic" release, and then the 9 packages are added to this
>> release to form the "Full" release.  The Full release is the one
>> provided on squeak.org, although the Basic release is also available 
>> on
>> the ftp site.
>>
>> 2. The plan I described in my previous message:  Fork the update 
>> stream
>> now into a Full stream in addition to the regular (Basic) stream.  The
>> 9 packages are added to the Full stream shortly by loading the 
>> "upgrade
>> to full" package from SqueakMap.  When we move to gamma, a Full 
>> release
>> image (candidate) is created from the Full update stream, and a Basic
>> release image is created from the regular stream.  The Full release is
>> provided on squeak.org, and the Basic release is available on the ftp
>> site (as with option #1).
>>
>> 3. Daniel's suggestion:  Keep just one update stream.  Add the 9
>> packages to the update stream now.  This becomes the Full release,
>> there is no separate Basic release, although there are "removal"
>> packages which should work to get you down to Basic.  At the beginning
>> of 3.7alpha, the 9 packages are removed again.
>>
>> Any thoughts on these?  My thoughts:
>>
>> The main problem with option #1 is that no one is really testing the 9
>> external packages right now to make sure that they work, so there will
>> probably be problems when the Full release is put together for 3.6.
>> But otherwise it's simple.
>>
>> Option #2 is a bit more complicated and splits the folks testing into
>> two groups, but is otherwise okay IMHO.
>>
>> Option #3 might work, although I'm not sure if everyone wants to go
>> without a Basic release.  Also, I'm not sure if we have working 
>> removal
>> packages for all 9 extra packages right now if someone wants to strip
>> down to a Basic release.  (And this does sort of take us back to
>> stripping/shrinking to get a smaller image.  Although Daniel has a
>> point that the important thing is that the refactorings have been done
>> so that the removals should be simple.)
>>
>> At some point quite awhile ago I think Goran suggested just providing 
>> a
>> Basic release which has the 9 extra packages bundled, and a button or
>> some simple mechanism in the image to upgrade to the Full release.
>> This is sort of a variation of option #1.  Although I tend to think
>> that we should just provide a Full image as part of the release 
>> instead
>> (in addition to a Basic image if needed).
>>
>> Also, one other thing to think about is how things might be different
>> when we have SqueakMap 1.1, and we get to release 3.7final.  SM 1.1
>> will support versions and dependencies/configurations on top of that,
>> which solves some important problems, but I'm not sure if it resolves
>> the issue we're talking about here... at least not while we're still
>> chopping away at the image.  We'd still like a way for a largish 
>> number
>> of people to test a beta Full image/configuration before it goes 
>> final.
>>   Hmm, haven't thought about that enough yet.  But whatever we do for
>> 3.6, we should think about whether we'll be doing something different
>> for 3.7.
>>
>> (Enough rambling for now...)
>>
>> - Doug
>>
>>
>> On Wednesday, August 13, 2003, at 05:22 AM, Daniel Vainsencher wrote:
>>
>>> First, my position is that as long as you're doing the release work,
>>> its
>>> your call. Now, my opinion is that an extra/early fork splits our
>>> testing effort, which will result in less quality/more
>>> fix-backport-work.
>>>
>>> I also don't think that adding all that stuff back/removing it is 
>>> such
>>> a
>>> problem. IMO, shipping actual stripped image is not really that
>>> important at all - the process of making packages removable in a way
>>> that reloading it doesn't change existing code is the valuable part 
>>> of
>>> the process. Why? because someone that wants to strip an image bare 
>>> can
>>> now do it trivially, and cleanly because the design problems are
>>> solved.
>>>
>>> I am almost sure the "removal" scripts won't work, because that isn't
>>> really what they are. The Celeste removal is actually 99% a 
>>> significant
>>> refactoring of the old code (which doesn't exist any more) and a one
>>> line removal. The up side is that the removal when we enter 3.7a will
>>> be
>>> a one liner (well, one per package, probably :-).
>>>
>>>> From what you say, it sounds to me like we should send the convert 
>>>> to
>>> full, let people test/fix the full image, release it, and then 
>>> restrip
>>> it when we enter 3.7a.
>>>
>>> It does seem a little annoying that SARInstaller should ask you about
>>> loading DVS/MC every time you install something, BTW... I wonder if
>>> loading DVS/MC quietly is really that big a problem?
>>>
>>> Daniel
>>>
>>> Doug Way <dway at riskmetrics.com> wrote:
>>>>
>>>> I've been wondering about how to handle this... I know you posted
>>>> about
>>>> this awhile ago. (sorry for not responding sooner)
>>>>
>>>> I'm not sure we want to add all of the packages again in the
>>>> "mainline"
>>>> update stream, since we've gone through all of the trouble to remove
>>>> them in the first place.  (I think Goran especially would not be 
>>>> crazy
>>>> about this idea. ;-) )  And then I guess we would have to remove 
>>>> them
>>>> yet again when 3.7alpha started, which seems sort of silly.  Also, 
>>>> I'm
>>>> not sure if the old removal scripts from early 3.6alpha will still
>>>> work
>>>> in 3.7alpha, although they would probably mostly work.
>>>>
>>>> However, I do agree with you that we have a problem with these 
>>>> removed
>>>> packages not being tested much.
>>>>
>>>> I'm a little hesitant about this, but one thing we could try is
>>>> creating
>>>> a dead-end update stream fork for the 3.6 Full release, now.  This
>>>> would
>>>> set the SystemVersion current name to something like 
>>>> FullSqueak3.6beta
>>>> instead of Squeak3.6beta.  The update stream machinery can handle 
>>>> this
>>>> as a forked stream separate from the others, just like 3.7alpha can 
>>>> be
>>>> forked from 3.6gamma.  Then we could add all of the Full packages to
>>>> the
>>>> Full update stream, and this Full stream would continue to become 
>>>> the
>>>> 3.6gamma and then 3.6 final Full release, and would end there.  The
>>>> mainline (Basic) 3.6beta stream would continue on to become the
>>>> 3.7alpha
>>>> stream, and also the 3.6 final Basic release.
>>>>
>>>> A prompt would need to come up when the fork happens, of course, 
>>>> which
>>>> would describe the two options, hopefully encouraging some people to
>>>> try
>>>> the Full fork if they like to work within the traditional full
>>>> multimedia image, even though it's a dead-end.
>>>>
>>>> This would be some extra work for me... for example I would have to
>>>> post
>>>> 3.6beta bugfixes to both streams.  That's not particularly 
>>>> difficult,
>>>> though, and the bugfixes should be the same for both streams.  (The
>>>> bugfixes would not overlap anything in the added packages.)  Also we
>>>> could post period updates to the Full stream to load the latest
>>>> packages
>>>> from SqueakMap.  (In this case I think it probably is okay for the
>>>> Full
>>>> stream to directly update from SM.)
>>>>
>>>> How does this sound?
>>>>
>>>> - Doug
>