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