[squeak-dev] Cleaning unneeded UpdateStreamDownloader

Edgar De Cleene edgardec2005 at gmail.com
Sun Jul 22 23:32:47 UTC 2018


Good explain why do not use  .cs
Realize don’t think in a collaborative system versus a one man ruling all.


On Sun, 22 Jul 2018 at 19:01 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 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 at 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/20180722/4597f09d/attachment.html>


More information about the Squeak-dev mailing list