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:
> 
> Daniel Vainsencher wrote:
> 
> >Doug, July 26th you wrote that PWS, B3D and VMMaker caused load trouble.
> >Does anyone know whether they load clean now?
> >
> 
> I just tried the "upgrade to full" package, and they all seem to load 
> cleanly now.  Hooray!  (I think most of this is due to Ned fixing the 
> accidentally removed method in the latest version of the SARInstaller.)
> 
> Well, relatively cleanly, anyway... a couple of packages (Games and 
> Balloon3D) bring up a prompt about wanting to install DVS, which I said 
> "no" to each time.  Also, one package (Games) requires that you enter 
> your initials for some reason.  But other than that, things seem to load 
> smoothly.
> 
> As to whether the packages actually work, I'm not sure... there may be 
> deprecation warnings all over the place when you run things. ;-)
> 
> >I think we should load the
> >stuff that works soon, to make use of the beta period.
> >  
> >
> 
> 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