[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

Casimiro de Almeida Barreto casimiro.barreto at gmail.com
Mon Jun 29 02:15:27 UTC 2009


Em 28-06-2009 21:40, Igor Stasenko escreveu:
> (...)
> Automagically by you, since you currently a release team member and
> must pay attention to every bit of code ever written for squeak :)
>
>    
>> (...)
Not the case for any kind of summoning. But there should be some level 
of testing. At least to detect dead links to repositories and to detect 
orphaned packages. If a package is orphaned long enough, there should be 
a policy for tagging and moving it to a special place... Regarding to 
orphaned packages I like Fedora model for announcing it and seeking for 
new maintainers. I also think that their model for responsibility 
delegation chain (it is far from perfect and sometimes not quite 
"democratic" but works most of time) is quite reasonable.

But I guess that open software community is quite rich of good examples 
for maintaning distributed development.

This discussion resembles other inside Fedora community: what should be 
in/out of a distro and how to maintain it. There are three proposals: 
Squeak, Pharo, Cuis. I'll tell you what I don't like in Pharo/Cuis 
proposals: they resemble me Brazilian way of solving things: you have 
something that's just not working as you wish. Instead of correcting the 
circumstances that lead to the problem, people start a new project 
saying: "now everything will be all right". Later the so called solution 
is suffering from the same problems and people launches a newer project 
to fix what went wrong with the predecessors. And there are 3 projects 
running in parallel. Redundancy of effort, high costs (even in terms of 
dedication of people struggling to keep pace in what is happening 
around) and futile disputes are the only results.

I think there's nothing fundamentally wrong with squeak. The question is 
how to organize things. How to classify things as "core", "contributed" 
and "3rd party". How to keep things up to date. How to obsolete things.

It may be boring, but I think that many things could be formalized.

    * First there are the leadership meetings on Wednesdays. The agenda
      of the meetings as well as their minutes could be placed at the
      www.squeak.org/Foundation. There should be a place where people
      could suggest topics to be included in the agenda. I know that
      much has been done via e-mail lists but for people (like me) who
      have to deal with large amounts of email these lists may be
      unpractical. Besides, keeping things public is a good way for
      letting people decide if they want or don't want to use squeak.

    * As this discussion (about future of Squeak & Pharo) made clear, it
      is urgent to define what is in and what is out of Squeak. Since
      there's a real concern about back compatibility and as things are
      getting big and sometimes non-maintained, I would suggest that
      documenting things is essential.

    * In my opinion, it would be interesting to create a mechanism for
      responsibility delegation regarding to maintenance. Regarding to
      distributions it would be interesting to create a mechanism for
      evaluating the suitability of packages to be included (like
      looking that the packages don't have dependencies outside the
      distribution and things that can lead to a situation where it is
      impossible to assure their maintenance). I don't think that a
      situation where a single person is responsible for a critical part
      of a distribution is acceptable: whenever such situation is
      identified the leadership should seek for additional people.

    * In my opinion, it would be good if some sort of
      financial/corporate support could be granted. It would allow to
      have people involved in "non exciting" tasks. Again: corporate
      support doesn't translate in any kind of servitude and it can help
      to grow the universe of Squeak users. Besides, good marketing is
      essential: if you get good media it is more likely you'll be
      granted more and better projects... more people will pay attention
      to you.

Just a last thing about croquet. It was meant to rock but didn't... I 
tell: (1) poor documentation (how in hell I use it???) (2) lack of 
marketing (yeah... even inside university good marketing is essential). 
Many people just didn't figured out what it was meant to (3) performance 
issues (intensive use of GL, etc).

Good night all,

CdAB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090628/0b9d992a/attachment.htm


More information about the Squeak-dev mailing list