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

Igor Stasenko siguctua at gmail.com
Mon Jun 29 02:32:35 UTC 2009


2009/6/29 Casimiro de Almeida Barreto <casimiro.barreto at gmail.com>:
> 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.

This is what is called development: learn on mistakes and move forward.
An opposite to this is stalling: do nothing, eveyone is happy. End of story.

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

How many companies in the world producing a cars in parallel?
Should they merge under a single banner & start producing a single,
good for everyone car?
Or should they stop producing a cars at all, because all of them would
break someday, or get obsolete?
Imagine, how many money & man hours could be saved! :)

> 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.
>
You are free to post agenda items at any time. Either in blog comments
area, or here on the list.
We are in need for your proposals, and declaring this constantly.

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

You know, all of this is good: Pointing at mistakes, drawing a new direction.
But for a success, there is one little thing is missing: where are
those people who stop talking and start doing something?
I can tell you, but i think you know it yourself.

No offense.

> Good night all,
>
> CdAB
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list