3.6 Full release testing (was Re: [BUG]? Upgrade to full image
script behavior)
Doug Way
dway at riskmetrics.com
Wed Aug 20 18:11:10 UTC 2003
goran.krampe at bluefish.se wrote:
>Michael Rueger <michael at squeakland.org> wrote:
>
>
>>Richard A. O'Keefe wrote:
>>
>>
>>
>>>- Can I be confident that updates to the Base image will have been
>>> *tested* with all the packages in the Full image, and that updates
>>> will check for the presence of packages they are incompatible with,
>>> so that I will be warned about and allowed to cancel an update that
>>> might break the Full image?
>>>
>>>
>>No, no, and not really doable in practice. Even MS with their gazillions
>>of testers fails to achieve this.
>>
>>
>
>You should be confident that the updates at least "load" in a Full
>image. I think Doug or whoever is in charge of the updatestream will
>ensure that at least. And perhaps he may also run the available Unit
>tests for the Base image that Marcus maintains. And perhaps even
>existing unit tests for the packages in Full (are there any yet for the
>famous 9?).
>
>But no manual testing will be performed - no time for that. Again, Doug
>can tell you how much of the above he does today before pushing it out.
>
>
Currently, I do make sure that any about-to-be-published updates
successfully load into a Basic image, of course. Now that we are
talking about "supporting" Full images following the same update stream,
I will plan on also making sure the about-to-be-published updates
successfully load into a Full image too, at least. (A Full image in
this case will be a Basic image with the "upgrade to full" script loaded
a few minutes prior.)
(The other thing I do test for right now is any conflicts between a
given update and more recent changes in the image and the other updates
in the batch. The ConflictChecker does this, and it has caught a few
update conflicts over the last few months, which I haved fixed on the spot.)
I'm not currently running any Unit tests, although that's not a bad
idea. Some of the famous 9 Full packages do have corresponding Unit
test packages, btw. (Scamper, Celeste, Games, at least.) I could give
this a try. Although we've also talked about having a server out there
somewhere running Unit tests on a regular basis.
Right now I'm working on making my life easier by creating a little tool
which collects a list of potential updates in a window (added from the
BFAV), and then lets me number them as a group, load/check conflicts on
all of them at once, broadcast them all at once, and send out the
[update - xxxx] messages. Right now I do these steps manually. This
tool is partly done.
>>>- Will packages that are not part of the Base image also have some
>>> kind of update stream, or will they only be replaced in toto on
>>> SqueakMap?
>>>
>>>
>>That is very much up in the air right now, part of the reason for the
>>many messages that have been flying around.
>>
>>
>
>Yes, this is in the air. I assume you mean the official Squeak packages
>(currently the famous 9) and not *all* packages on SM. I also assume
>that we will decide on a common strategy for these packages. But we
>haven't done so yet. Andreas has made a hack available for setting up
>updatestreams per packages that works with SM1. SM2 will include some
>fields for this.
>
>But perhaps we will instead choose to use Monticello for these packages
>and not "stream of a bunch of ChangeSets" at all.
>
Yep. :-) I'm not going to be spending any mental effort on this
particular issue anytime soon, there's enough other stuff to work on.
But perhaps a package owner may want to try setting up an update stream
for a package sometime soon. (probably after SM2 is out) Update streams
may be overkill for some packages, but for others it might make sense.
>>>- Is there _anything_ I can do to keep a Full Squeak current, or do
>>> I just jump from official release to official release?
>>>
>>>To be perfectly honest, I have hitherto *preferred* "wait for the next
>>>stable release" to "keep quite current", but I have been feeling a bit
>>>guilty about that, because it's one of the main reasons why I haven't
>>>done any bug fix testing. The fact that a bug fix seems to work in my
>>>image does NOT imply that it works in a fully patched image, so I've
>>>felt that any bug testing I did would have been pointless.
>>>
>>>
>>So in practice not much is going to change for you then? ;-)
>>Seriously, I've also preferred to not update while I'm in the middle of
>>some development and the squeakland plugin image is also getting new
>>releases twice a year at the most.
>>As I said, the update stream is called alpha for a reason.
>>
>>
>
>If you want to keep up with alpha/beta/gamma streams then just go ahead.
>The stream is there for a reason. But it is currently not only used as a
>general update mecanism for a stable release.
>
>
You might not want to do large projects on top of a Full alpha image,
but it's not hard at all to just keep a Full alpha image (3.6) around
and update it periodically, in addition to a stable release image
(3.5). If you see a bug in your stable image, you can check your
updated alpha image to see if the bug is also there, and then submit a
bug report/fix, and thus participate in the bug reporting/fixing process.
- Doug
More information about the Squeak-dev
mailing list
|