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
|