juan at jvuletich.org wrote:
>> Juan Vuletich wrote:
>>     
>>> Agreed. Forks have their reasons to exist. They are not a bad thing.
>>> And if you believe you have the magic recipe to join them, you're
>>> wrong. Each fork might have different reasons. For example, it looks
>>> like Pharo exists because of people issues, not technical. So most
>>> likely, they will not want to join back with Squeak, no matter what
>>> process we have. As another example, Cuis, my own fork exists because
>>> I want to clean the Squeak kernel. So, it can _not_ use the Squeak
>>> kernel! Before designing the whole process after the idea of joining
>>> forks, we should ask "Do forks want to join?" "Do forks want to adopt
>>> this process and tools?"
>>>
>>>       
>> Well, once the image is split entirely into packages and we have an
>> automatic build tool, won't the forks turn into configurations for that
>> tool? i.e. instead of having Squeak and Pharo, we have the Squeak people
>> distributing their own build tool config that loads packages A, B and C,
>> while the Pharo people have a config that builds their images from
>> packages X, Y and Z. Over this you could then load LevelPlayingField to
>> provide a common API for portable code.
>>
>> With that sort of setup, forks should disappear, replaced by packages
>> and build configurations.
>>
>>     
>
> Awesome! My reply to you is exactly the paragraph you are quoting. Please
> read it again. I already said why I presume Pharo will not join. I also
> said why Cuis will most likely not join. Cuis could be integrated into
> Squeak (i.e. used as a starting point to build the Squeak kernel on which
> packages are loaded), but not joined (i.e. taking the Squeak kernel as a
> base to build Cuis).
>
>   
I'm afraid you misunderstand. I'm not talking about joining the forks
together, I'm talking about forks as such being no longer necessary.

After all, if all images are built from a collection of packages (*not*
a core image+packages, I include building the kernel from packages like
Spoon) then what exactly will distinguish an official Squeak, Cuis or
Pharo image from each other or any random image someone makes? Only the
stamp of approval put on them by the owner of the build configuration.
Of course, some people may see these builds as forking but I don't see
it that way since all that changes is the arrangement of packages, not
the code itself.

This is looking a fair bit into the future though...