goran.hultgren at bluefish.se wrote:
> <diegogomezdeck at consultar.com> wrote:
> > To say it shortly: Squeak is dieing in front of us...
> I wouldn't say "dieing". But we are suffering a bit.
How about an alternative explanation? Suffering is what learning looks
like, when you're still not sure you'll get it eventually... :-) The
good part is that we later forget how many time we fell on our ass until
we learned to walk.


> > The bureaucracy is killing us.  The steps to get a fix
> > approved are, in most of the cases, more difficult and time consumer than
> > the fix itself.
> 
> Well, in this regard I am perhaps inclined to agree a bit. 

Well, I disagree ferociously :-)

> And personally I haven't
> tried the process so it may be simpler than it sounds.

I do think this is part of it :-)

Seems to me most of the pain and uncertainty that was part of submitting
something is now potentially gone. 
- If you read the harvesting pages, you know what you're supposed to do,
you know what your change is supposed to be - no need to guess much on
whether it'll be deemed worthy of inclusion. 
- If you get reviewers, you know how to get concrete feedback, which was
sometimes hard in the old times.
- It's trivial to submit stuff, just go to your changeset, and press
"mail to list"

BTW, if someone thinks otherwise, pipe up.

The main pain now is that 
- harvesting is still too slow, because it of all the obvious reasons
- The reviewing, which is now almost separate from harvesting, is still
as much a pain, as it always has been, except now it's shared, not just
among the Harvesters.

I don't have a ready source of funding to hire Tim, but we can do
something about the slowness and friction of the two above.

Practically, the friction remaining in Harvesting (as far I know, some
parts of the process are done only by Doug) is the same as in Reviewing.
There's a basic process for simple reviews, and a few extra steps for
deeper review/testing.

Review -
- listing the stuff to be reviewed (from the fixes archive/latest on the
mailing list), 
- choosing what to check, 
- downloading it, 
- reading the code/comments
- writing ones findings

Testing/Running diagnostic tools/Reading the code in context
- getting a clean current image, 
- (get the code as above)
- loading the code
- running it, running tests, running Lint, whatever
- discarding the image.

Most of these steps are silly, take time and effort, and add friction
and reasons to put off reviewing someone elses code/Harvesting it.

However, most of these steps can be automated. If someone wants to
tackle this, even the simplest hack that helps would be a service to the
community. After we take out the pain from reviewing, we should make
reviewing other peoples code a hobby, and then the remaining steps of
harvesting won't be such a bottleneck.

Daniel