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

Cheers,
Juan Vuletich