So is the outcome of this discussion that UpdateStreamDownloader
should be removed?

On 7/23/18, Edgar De Cleene <edgardec2005 at gmail.com> wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>