On 23 April 2013 22:48, Chris Muller <asqueaker at gmail.com> wrote:
> On Tue, Apr 23, 2013 at 9:40 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 23 April 2013 15:06, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>> On 2013-04-23, at 15:40, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>
>>>> On 23 April 2013 14:20, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>> On 2013-04-23, at 11:55, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>>
>>>>>> And updates-fbs.232 makes sure that Nebraska, XML-Parser, Universes
>>>>>> don't accidentally find their way back into the trunk image through
>>>>>> the update stream.
>>>>>
>>>>>
>>>>> Why is that? Why would we not want to have the XML parser in trunk? The plan was for the build server to use an image that didn't have the packages, but load the trunk map to build a full image. Otherwise, how would we update the XML package?
>>>>
>>>> The plan was to remove this package, and more along the way, from
>>>> Trunk. The _release process_ would _reload_ the packages, producing
>>>> Squeak 4.5 artifacts that are apparently unchanged in functionality.
>>>> The output of the SqueakTrunk build meanwhile continually shrinks.
>>>
>>> That is not how I understood the plan.
>>>
>>> Trunk is our community's primary workplace. It needs to include all community-supported packages, and they need to be automatically updated when we hit the "update" button, so everyone is in for the fun of testing.
>
> Universes is in the image, but you can bet it's not getting tested
> beyond its test suite.
>
>> Trunk has never included all community-supported packages.
>>
>>> The minimal image is mainly used by the build server. When it updates from the trunk map, it does not update the unloaded packages, because it has the UpdateMissingPackages preference disabled. Then it can run the "minimal" tests to ensure the system works without the unloaded packages.
>>
>> So this is set by MCMcmUpdater updateMissingPackages ? I'll amend my
>> scripts accordingly.
>>
>>> The result of the trunk build is the minimal image + all unloadable packages, which get pulled in by the trunk update map (UpdateMissingPackages enabled). Then it can run the "full" test suite again.
>>
>> That's not how it's set up, and I thought I'd made it clear. But OK.
>
> I thought you did, too.
>
>> Right now the build server uses two main jobs to create a new image.
>> SqueakTrunk takes a hand-prepared "minimal" 4.5 image and updates it
>> from trunk. In a copy, it runs all the tests in that image. Then
>> ReleaseSqueakTrunk takes SqueakTrunk's output and loads various
>> packages (39Deprecated, 311Deprecated, Nebraska, Universes,
>> XML-Parser) into the image. This image is the thing people will
>> download.
>
> My concern about this approach to deployment is that people will be
> downloading an image that has never been tested -- just a likeness of
> the trunk image since it's had packages unloaded and then reloaded,
> with all associated unload and initialization scripts, etc.
> Technically, the state of the image we release for download never gets
> tested by individuals.

Well, to be picky, I'd argue that the artifact spat out by
ReleaseSqueakTrunk requires people to test it before we release it to
ftp.squeak.org. So while, yes, you're right, these are also labelled
as alpha class artifacts.

> That's where I think Franks approach has an advantage -- people who
> USE XmlParser will have to load it where it was previously unloaded.
> Which means they're testing the unloaded/reloaded version of
> XmlParser, not the one that's always been safely nestled into the
> image for years.

My main concern with keeping stuff out the core image is that it's
just so easy to add a dependency that you really ought not to. Like
that Graphics/Morphic dependency, for instance. And if you add one,
it's just as easy to turn that into a cyclic dependency. And then
persistent state gets thrown in and suddenly it's really, really
difficult to untangle things.

>> As _I_ understood it, when a package is ripe for unloading, it gets a
>> new CI job, whose purpose is to take a SqueakTrunk image, load the
>> package, and run the package's tests. (This is the ExternalPackages
>> job.) This way, we can know that, say, XML-Parser still works.
>
> That seems to offer the best of both words -- continued testing of
> external packages and also a smaller image for those who don't use
> XmlParser.

And eventually, tiny images that swarm like bees!

frank