Squeak 3.8 status

Chris Muller afunkyobject at yahoo.com
Tue Aug 3 19:01:25 UTC 2004


May I agitate this thread with intentions of good?

In my personal experience, the actual submission of changes/fixes has been
difficult and laborious.  After the actual submission, some of them further
required continued hard lobbying/nagging/reminding, etc.  Even after hours of
work, many never made it.

With such a high "cost" of getting a change, it really emphasizes what Lex
seems to be complaining about..  That the process does not support small,
simple, safe fixes.  What if someone merely wants to correct a class or method
comment?  There's no way that's worth going through the pain of the current
process, not only for the submitter but for the harvester, and that's a shame
because lots of "baby-step" improvements can contribute a lot to the maturity
of a system.

What if we used an approach where, say, during the alpha phase, the community
*as a whole* had an opportunity to make and eat its own dog food.

  - anyone can submit a change/fix that will make it to a publicly-accessible
update repository ("the update stream?")
  - anyone can bring in these current public changes from others a la "update"
mode, i.e., they can see the change before they import it.  Also, people will
learn to save their image first..  :)
  - We use a tool (BFAV?) that allows people to comment and possibly even
"vote" on each particular change.
  - The same tool could be used to improve a particular change based on others
comments, of course.

It's a different kind of pain, but it opens the door for a flood of small fixes
we could get in during alpha phase that would be unencumbered by the
bureacracy.

People will undoubtedly submit stuff that doesn't belong.  If that happens, the
community will vote "no" on it.  People will undoubtedly submit stuff that
breaks the image and, if so, people will attach feedback to it that says,
"beware, this hosed up my image.." so that others will be more wary of it and,
later, if not fixed, vote "no" on it.

In the beta phase, once we *have them* all in there, it would again be up to
the community to vote and clean up.  Perhaps no more "new" changes would be
accepted other than improvements to the ones that were submitted during alpha
phase.

To realize this, the tool would have to support all parts of this process;
submitting, commenting, voting, accepting, rejecting, etc.  The idea is for the
tool to be a central point of communication and management of
changes/fixes/improvements for the community, by the community.

This is a high-level suggestion; I realize there are a lot of "holes" and
technical challenges to implementing something like this.  Maybe BFAV has us
already half-way there..  But the premise is that the harvesting process should
be able to accomodate a *growing* community; so that as the community grows, it
is more capable of sustaining its own growth, rather than obliterating three or
four harvesters time and choking on the bottleneck in the process.

 - Chris



More information about the Squeak-dev mailing list