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