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.