3.6 Full release testing (was Re: [BUG]? Upgrade to full image script behavior)

Doug Way dway at riskmetrics.com
Sun Aug 17 05:30:34 UTC 2003


(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



More information about the Squeak-dev mailing list