[squeak-dev] Instructions for updating trunk undate config

Eliot Miranda eliot.miranda at gmail.com
Wed Feb 14 20:44:48 UTC 2018


Hi Bert,

On Wed, Feb 14, 2018 at 1:04 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

>
> On Tue 13. Feb 2018 at 20:38, Chris Cunningham <cunningham.cb at gmail.com>
> wrote:
>
>> Hi Eliot,
>>
>> On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>
>>> Hi Chris,
>>>
>>>
>>> > On Feb 10, 2018, at 1:48 PM, Chris Cunningham <cunningham.cb at gmail.com>
>>> wrote:
>>> >
>>> > This one I'm going to need some help on, having never done this before
>>> (obviously).
>>> >
>>> > -----
>>> > When and How to change the trunk update configuration:
>>> > * When you are adding a new package to trunk, update the configuration
>>> with the new package (just because a package is in the repository does not
>>> mean it is loaded)
>>> > * When you are removing a package from trunk, update the configuration
>>> to remove the package (and follow instructions for removing the package)
>>> > * When methods are moved from one package to another - primarily when
>>> they are used in the update logic - then create an update with the package
>>> where the method is removed and where the method is added in the same
>>> update configuration
>>>
>>> That's not the safest.  The safest is to create a configuration with the
>>> package to which the method is moved, but still containing the version of
>>> the package from which the method had moved which still had the method.
>>> This way, the package from which the method is moved will be marked dirty
>>> but there is no chance of the method being lost.
>>>
>>> I wasn't sure where the conversation between you and Bert left off on
>> this subject.  I can certainly change this to be this way - especially
>> since it is safer (leaving the Bert enhancement to cover places where we
>> weren't aware that happened, maybe.  Although we should be aware.).
>>
>> Another question: should we ALWAYS create a config when a method (or
>> class) moves from one package to another?
>>
>> -cbc
>>
>
>
>
> IMHO we have way too many config maps already.
>
> We don't need any config maps even for moving methods between packages.
>
> The only time when you actually need an explicit config map is when you
>  are doing open-heart surgery on the kernel.
>

I agree.  But the question is whether we should mention this or not.  For
me, being able to do open heart surgery reliably is really important.  And
at the same time having a reliable update process is really important too.
 occasionally we've had broken updates, due to incorrect update maps,
causing temporarily missing methods, etc, when moving code between
packages.  These episodes are painful; they're difficult to debug because
the system is broken; they require meddling with packages and update maps
on the repository.  So do we err on the side of caution and document the
issue, along with caveats such as "this is hyper cautious; you really
shouldn't need to do this unless you're doing open heart surgery" or do we
not document it and endure the occasional, rare pain of fixing things when
they do break.  You know me; I'm quite conservative in these things and so
lean to the former.  But I'm happy to be contradicted here.

This is because besides the explicit config maps, the implicit map loaded
> at the end of the  updater usually takes care of everything. It is created
> on the fly by taking the last published config map and updating it with the
> latest packages from trunk.
>

I would at least like to see this detailed somewhere in Chris's
documentation of the process.


>
> Creating unnecessary config maps just slows down the update process.
>

Agreed.  I create them only when I think, most likely mistakenly given my
ignorance of Monticello update internals, that there's a chance I'm going
to break the system.  But unless I have a good understanding of the magic
I'm going to find it hard to avoid creating config maps.



> - Bert -
>
>>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180214/2fff1c46/attachment.html>


More information about the Squeak-dev mailing list