Gradually minimising Trunk (Re: [squeak-dev] The Trunk: Graphics-fbs.209.mcz)

Chris Muller asqueaker at gmail.com
Tue Apr 23 21:48:16 UTC 2013


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.

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.

> 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.

>> We had this discussion before, I thought, and we agreed that only truly deprecated packages are removed from the trunk update map, after the deprecation period. As soon as they are removed, the trunk build would not load them anymore, resulting in a smaller trunk image.
>
> The main reason behind updates-fbs.232 is to stop the SqueakTrunk
> image from loading unloading packages, so if #updateMissingPackages:
> lets me do that, let's delete the update.


More information about the Squeak-dev mailing list