[squeak-dev] Cleaning unneeded UpdateStreamDownloader

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Jul 22 22:01:30 UTC 2018


2018-07-22 17:17 GMT+02:00 Edgar De Cleene <edgardec2005 at gmail.com>:

> Could send this to Cuis list ?
> Like what Juan have to said.
>
> If you look at
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk/blob/master/Documentation/CodeManagementInCuis.md
you will see that package had to be introduced in Cuis for easing
contributions.
Why packages are not managed with change set? Because it would not scale...
They are handled by git/github.

Then there is a big ball called Cuis Core which is thus kind of special
package still managed with change set...

First, I ask you: how many people can integrate the change set in the core
image apart Juan?
See for example, when by miracle a change set is integrated immediately
(otherwise it would have to change update number),
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blame/master/CoreUpdates/3369-Make-SmalltalkEditorMenu-dynamic-HernanWilkinson-2018Jul10-18h51m-HAW.1.cs.st
Even if not written by Juan, it is integrated by Juan.
And you see a linear history without branches in the update numbers. But
pull requests are not necessarily linear.
It means that Juan so far deploy efforts to sort out the changes and
integrate them.
It also fits well his volunty to control Cuis.
You see that Cuis is an exact example of
https://en.wikipedia.org/wiki/Benevolent_dictatorship.
It's not our model in Squeak.

Second, I maintain that it would not scale for us.
There are 14 contributors in
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/graphs/contributors
and 81 closed pull request in
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/pulls,
and only a subset of them concerning change sets.
So probably not many conflicts so far.
Please compare to how many package versions in Squeak inbox and treated
inbox.

Third, what if I forked
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/CoreUpdates
and made several changes, some accepted and integrated by Juan, but with a
different update number, some yet not integrated, some refused...
How am i supposed to merge? That's the manual handling of change sets that
typically is difficult and error prone, and that I don't want to live with
anymore.

Last, since there are packages, why do Cuis Core has to be handled
specially?
Because of live updating. We use the image to change the image, so from
time to time, special actions (scripts) are required for bootstrapping.
A good example is changing compiler or core features in Morphic.
This is the main reason for keeping changeset: git does not have anything
to offer for live update, git is designed for dead code.
So I guess that rather than inventing own new way to handle live update
thru git
(it could mean something as complex as the Pharo bootstrapping efforts),
Juan preferred to keep the .cs like he always did when the project was
single-manned.
This does not make .cs a good choice, just a default choice.

In Squeak we have same problem with live update.
We have to use the MonticelloConfigurationMap (MCM) for live updating the
image.
These live-update mcm are numbered, like the CoreUpdates are numbered in
Cuis.
They have to be loaded/merged in sequence because of bootstrap scripts, and
thus cannot be applied in arbitrary orders which severely limit the opened
branching model of git...

But a big difference with Cuis is that a new MCM is emitted if and only if
a bootstrap srcipt is necessary, not for every core change!
And a second enormous difference: these mcm do not contain code. They only
contain reference to package versions.
This is what enables the whole source code to be managed in a single way:
Monticello packages.
This gives possibility to browse every method edition unlike .cs.
This also give the possibility to merge with local image modifications
rather than overwrite like in Cuis
(though there is no guaranty that the bootstrap scripts will work in a
modified image, like with .cs).

I don't want to discuss more the choices of Juan. They were done in a
certain context that does not match ours.
He always refused to integrate MC for not bloating the Cuis image.
The will to be present on github guided him to this package solution, in
this context Monticello could be viewed more as an obstacle than a solution.
The live update problem forced him to be conservative with .cs with a scope
reduced to Core.
Given the smaller size of core code in Cuis and the benevolent dictatorship
model, it may last.

I can tell you that I used both .cs and MC and would never go back. One is
clearly superior.
For Squeak, .cs would be a big regression!



>
> On 22 Jul 2018, at 09:49, Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
>
> Hi Edgar,
> Yes, there are good reasons for not using .cs.
> .cs do not scale. Or history has to be purely linear, which does not
> happen in real world.
> Merging concurrent versions is impractical, or even impossible without a
> history of branches.
> I've used .cs for more than ten years in the 90s, and even with a team
> reduced to 3 persons, it was far from ideal!
> Some features would take time to implement, and inevitably lead to
> conflicts.
> We finally had to put version history in method/class comments
> (author+timestamp+reason of change).
> A poor man source code versionning that bloated the source code with
> orthogonal information...
>
> I separated UpdateStream in own package in 2013 for the purpose of
> removing it, but this is unfinished work...
> One has to check if there are not unique implementor sends leaking outside
> the package.
>
> 2018-07-22 13:20 GMT+02:00 Edgar J. De Cleene <edgardec2005 at gmail.com>:
>
>> I wish we have .cs as in old days , but some people like using clumsy
>> tools.
>> So if we do not use .cs anymore why have UpdateStreamDownloader and
>> related
>> to lo download .cs from server ?
>>
>>
>> Edgar
>> @morplenauta
>>
>>
>>
>>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180723/0122cda3/attachment.html>


More information about the Squeak-dev mailing list