On Mon, Jul 23, 2018 at 12:27:05PM +0200, H. Hirzel wrote:
> So is the outcome of this discussion that UpdateStreamDownloader
> should be removed?
> 

I would be happy just to see UpdateStreamDownloader get a good class comment
that explains what it is, and that clarifies the difference between our current
Montecello based update stream and the older change set based stream.

An update stream is not a version control system. The update stream that we
use today happens to be built on top of Montecello, but if we ever wanted
to decouple the update stream from the version control system (for example,
if someone wanted to use git for version control), then it might be important
to have a simple change set based mechanism that works independent of the
version control systems.

I can also imagine a scenario in which we would want to provide some kind
of "mirror" of Squeak trunk on GitHub in order to make the system more visible
and accessible to the world at large. In that case, it might be helpful to
have a change set based update stream that follows the real one in Montecello.

Dave 


We do not currently use the UpdateStreamDownloader mechanism, but I think it
is import


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