[Pharo-project] [squeak-dev] Squeak 4.x should adopt Pharo 1.0

Stéphane Ducasse stephane.ducasse at inria.fr
Tue Aug 11 08:14:25 UTC 2009


good summary :)
We started pharo because we could not move anymore.
We will continue to pay attention to what they other forks are doing.

Stef

On Aug 10, 2009, at 11:10 PM, Miguel Enrique Cobá Martinez wrote:

> El lun, 10-08-2009 a las 21:07 +0100, Keith Hodges escribió:
>> Dear All,
>>
>> As far as I see it the only sensible way ahead for squeak 3.11 is to
>> adopt Pharo 1.0 as the next base version of squeak (i.e. 4.0), and to
>> begin a series of initiatives to promote compatibility with squeak
>> pieces that pharo doesn't support.
>>
>> The previous squeak 3.11 vision accepted, and now rejected, by the
>> squeak board was to develop a process that would allow squeak to  
>> harvest
>> the contributions of all the other forks, or other major initiatives,
>> and for significant contributions to be shared by all the forks.
>>
>> All of a sudden there was an "oh no pharo is ahead of us" panic that
>> ensued last month as a result of new squeak-dev people that were not
>> involved in, nor seemed aware of the goals of the 3.11 process.  
>> Within
>> this process Pharo may simply be viewed as a research project carried
>> out on behalf of the wider squeak community, that will be  
>> harvestable in
>> good time.
>
> I don't agree with you on this point. Pharo has its own merits to  
> exists
> and it didn't fork as a "research project" for the squeak community.
> As its web page states, its goal is:
>
> "to deliver a clean, innovative, open-source *Smalltalk*"
>
> emphasis mine. Not a clean Squeak.
> As the day pass the foundations grow stronger and itself gains more  
> and
> more identity and independence. This, if nothing really big happens on
> Squeak, will attract more developers and new users. There is no date  
> yet
> to deliver a new version of Squeak, and this, together with the Pharo
> 1.0 release, will be less energy to try to maintain code for several
> forks and several packages will choose to support the one with more
> *apparent* users.
> What I want to say is, there is, as each day pass, less homesick for  
> the
> past and more joy for the future.
>
>
>>
>> However now that this idea is no longer going to be developed, we  
>> need
>> to limit the number of diverging active forks as much as possible,
>> rather than creating new ones ("trunk" makes the problem worse not
>> better).
>
> This is a point that I have never accepted of your thesis. There is no
> way to put all the "forks" in the same
> process/mindshare/goals/repositories. It is impossible. Even if they  
> do
> it just for upsetting people. This isn't going to happen.
>
> The forks, as the young people, want to be free, independents, of its
> parents. They don't want to be like their parents project but a little
> different. They WANT to be better (whatever this means to the fork)  
> and
> independent. They want to learn their own lessons.
>
> If for accident they happen to be compatible good, but if not, well,  
> as
> the Linux community can show, there can not be a single distro  
> neither a
> single code base that runs in every distro. How they solved it, by
> assinging mainteiner of each package that tracks the upstream project
> and adapt it to the specific distro. Something like this will happen
> with squeak/pharo/cuis. The upstream developers will have its
> development platform but someone else will adapt it to other  
> platforms.
>
>
>
>> Once the output of "trunk" is released in whatever form we will
>> then have yet another base image to manage code for, and I don't  
>> think
>> that that is an acceptable outcome.
>>
>> When it comes to the elections next year, if there is anyone who  
>> would
>> like to run on the "Squeak to adopt Pharo" ticket, then I will vote  
>> for
>> them.
>>
>
> If this happen, then good for both of the communities. But until this
> happen, most new users will learn by the lists about pharo and when
> trying and comparing it to squeak, will make its choice. Some of them
> will stay with squeak, some of them will try again squeak when a new
> release is made and some of them will stay with pharo for ever.
>
> One (at least me) can't be jumping or using several smalltalk versions
> (the same way that I don't like to administer linux of several  
> flavors,
> it add unnecessary complexity and work).
>
>> best regards
>>
>> Keith
>>
>> p.p.s. Bob is not going to be released as open source, if you would  
>> like
>> the ability to build your images daily, and run the test suites  
>> against
>> your deliverables, then please do email me for licensing terms.
>>
>
> This is really a sad thing to read. Of course it is your decision, bad
> for us as it sound as Bob was a very good piece of software. On the
> other side, this sounds also like a emotional response more than a
> rational one. But if the community can't use your code, well, like the
> BitKeeper on the Linux kernel code case, someone will have to think
> something.
>
>
> -- 
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




More information about the Squeak-dev mailing list