<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Em 28-06-2009 21:40, Igor Stasenko escreveu:
<blockquote
cite="mid:4a5f5f320906281740m29c066awc2d432315707a91d@mail.gmail.com"
type="cite">(...)
<pre wrap=""><!---->Automagically by you, since you currently a release team member and
must pay attention to every bit of code ever written for squeak :)
</pre>
<blockquote type="cite">
<pre wrap="">(...)</pre>
</blockquote>
</blockquote>
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.<br>
<br>
But I guess that open software community is quite rich of good examples
for maintaning distributed development.<br>
<br>
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.<br>
<br>
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.<br>
<br>
It may be boring, but I think that many things could be formalized.<br>
<br>
<ul>
<li>First there are the leadership meetings on Wednesdays. The agenda
of the meetings as well as their minutes could be placed at the
<a class="moz-txt-link-abbreviated" href="http://www.squeak.org/Foundation">www.squeak.org/Foundation</a>. 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.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>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.</li>
</ul>
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).<br>
<br>
Good night all,<br>
<br>
CdAB<br>
</body>
</html>