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

Frank Shearar frank.shearar at gmail.com
Tue Apr 23 14:40:10 UTC 2013


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.

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

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.

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

frank

> - Bert -
>
>> But if the XML package is external to trunk, it shouldn't be in the
>> update stream. The XML package belongs in an external, SqueakMap
>> hosted, package. Users can update that as and when new XML-Parser
>> releases are made.
>>
>> But right now we don't have that. The update map keeps pulling these
>> packages in.
>>
>> But it turns out I know less about update maps than I'd like, because
>> I _still_ get these packages loaded into my updated-from-a-minimal-4.5
>> image.
>>
>> frank
>
>
>
>
>


More information about the Squeak-dev mailing list