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