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

When you say "If all images are built from a collection of packages" you
are presuming what you are trying to prove. I believe that will never
happen. It might happen for Squeak (I won't hold my breath), but why would
other people adopt that process?

You say that the code itself doesn't change. Forks exists because people
want to change the code!

As I said before:
"if you believe you have the magic recipe to join them, you're wrong."
"Do forks want to join?" "Do forks want to adopt this process and tools?"
For some, the answers might be "yes". For others, they might be "no, thanks".

Cheers,
Juan Vuletich