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

> On 23 April 2013 14:20, Bert Freudenberg <[hidden email]> wrote:
>> On 2013-04-23, at 11:55, Frank Shearar <[hidden email]> 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.

> 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

>
> On 2013-04-23, at 15:40, Frank Shearar <[hidden email]> wrote:
>
>> On 23 April 2013 14:20, Bert Freudenberg <[hidden email]> wrote:
>>> On 2013-04-23, at 11:55, Frank Shearar <[hidden email]> 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.

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

>
> On 2013-04-23, at 15:40, Frank Shearar <[hidden email]> wrote:
>
> > On 23 April 2013 14:20, Bert Freudenberg <[hidden email]> wrote:
> >> On 2013-04-23, at 11:55, Frank Shearar <[hidden email]> 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.
>
> 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.
>
> 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.
>
> 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.
>

> On 23 April 2013 15:49, Bert Freudenberg <[hidden email]> wrote:
>> On 2013-04-23, at 16:40, Frank Shearar <[hidden email]> wrote:
>>
>>> 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.
>>
>>
>> Sounds good.
>
> It's not apparent how to do that. I thought I could just go to
> http://source.squeak.com/, log in, go to the Trunk project and delete
> the map, but updates don't show up in, say, the Latest tab. (They do
> of course show up elsewhere, like
> http://source.squeak.org/trunk/update-fbs.232.mcm).

> Am 23.04.2013 um 16:57 schrieb Frank Shearar <[hidden email]>:
>
>> On 23 April 2013 15:49, Bert Freudenberg <[hidden email]> wrote:
>>> On 2013-04-23, at 16:40, Frank Shearar <[hidden email]> wrote:
>>>
>>>> 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.
>>>
>>>
>>> Sounds good.
>>
>> It's not apparent how to do that. I thought I could just go to
>> http://source.squeak.com/, log in, go to the Trunk project and delete
>> the map, but updates don't show up in, say, the Latest tab. (They do
>> of course show up elsewhere, like
>> http://source.squeak.org/trunk/update-fbs.232.mcm).
>
>
> In the project overview, there should be an "Edit Configurations" action
> to the left. You want that.

> On 23 April 2013 15:49, Bert Freudenberg <[hidden email]> wrote:
>> On 2013-04-23, at 16:40, Frank Shearar <[hidden email]> wrote:
>>
>>> 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.
>>
>>
>> Sounds good.
>
> I need to push a new config (to include the new MorphicExtras-Tests
> package)... just to sanity check, I really should call this
> update-fbs.233, right? (In other words, skip the 232 number because
> that was for a deleted bad config.)
>
> frank

>
> On 2013-04-23, at 17:32, Frank Shearar <[hidden email]> wrote:
>
>> On 23 April 2013 15:49, Bert Freudenberg <[hidden email]> wrote:
>>> On 2013-04-23, at 16:40, Frank Shearar <[hidden email]> wrote:
>>>
>>>> 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.
>>>
>>>
>>> Sounds good.
>>
>> I need to push a new config (to include the new MorphicExtras-Tests
>> package)... just to sanity check, I really should call this
>> update-fbs.233, right? (In other words, skip the 232 number because
>> that was for a deleted bad config.)
>>
>> frank
>
> You can just reuse the 232 name, won't matter.

> On 23 April 2013 15:06, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 2013-04-23, at 15:40, Frank Shearar <[hidden email]> wrote:
>>
>>> On 23 April 2013 14:20, Bert Freudenberg <[hidden email]> wrote:
>>>> On 2013-04-23, at 11:55, Frank Shearar <[hidden email]> 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.

> On Tue, Apr 23, 2013 at 9:40 AM, Frank Shearar <[hidden email]> wrote:
>> On 23 April 2013 15:06, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 2013-04-23, at 15:40, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 23 April 2013 14:20, Bert Freudenberg <[hidden email]> wrote:
>>>>> On 2013-04-23, at 11:55, Frank Shearar <[hidden email]> 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.