Squeak 3.8 status

lex at cc.gatech.edu lex at cc.gatech.edu
Sun Aug 1 20:52:50 UTC 2004


=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
> On 27 juil. 04, at 10:14, Marcus Denker wrote:
> > If you depend on squeak, you should try to get involved with the 
> > harvesting process (or work on improving/replacing that process).
> > You can view that as an "investment" in your own future.
> 
> I totally agree with marcus. It is CRUCIAL that people making (or 
> wishing) to make money with Squeak invest also in the process. Note 
> that for me I could live happy with any image I patch
> and do not care to give the result back to the community. In general 
> this costs me to send/harvest changes and I do not get money (nor wish 
> to make money with squeak).

I disagree.  The current harvesting process is quite inefficient, and we
need to fix it, not get even more people to work on it.  It is not a
good use of time to go through endless patches, most of which any
individual reviewer cannot add input to.

To put it another we, we already have TONS of volunteer effort in
Squeak.  It is crazy to suggest that we need even more before we can
make progress.  Somehow, we need to figure out how to rationally use the
tons of effort we already have.


To show what I am talking about, let me give you a quick story.  I
received an email a couple of days ago asking that I resubmit a FIX and
this time include a test case.  Actually, the post did include a test
case; it simply wasn't in SUnit form.  When I tried to write one, I
noticed that the code was no longer broken!  It turns out that someone
else had fixed it, this time with a SUnit test, and had their fix
included.

What do we see from this example?

	1. Email was wasted because a clear fix is not done in the most perfect
beaureacratic way.  All someone had to do was run the example one-liner
that was broken, look at the patch, try the patch, run the code again
and see that it was fixed.
	
	2. Multiple people have fixed the same bug.  This is wasteful.

	3. Everyone is having trouble searching BFAV.  At least two people did
not realize the same bug had already been fixed: the person who emailed
me, and the other person who fixed it.  I myself wasted time trying to
build a SUnit test case for something that had already been fixed
without my noticing.
		
	4. On the whole, much more effort was expended talking about this bug
and the different fixes, than was spent solving the problem itself. 
This patch changes two lines of code, for a grand total of 14
characters.  (It changes "Number" to "Integer" in two places.)  Even
going through an expedited cross examination would have been overkill
for such a tiny patch, but when you look at the quite slow process that
happened in practice, it is truly awesome how inefficient we were at
dealing with this bug.

	

My favorite direction to go in would be to put reasonable people in
charge of various parts of Squeak, as we have already begun to do so. 
And if some part of Squeak is too obscure for anyone to volunteer as the
maintainer of it, we shouldn't lose too much sleep that it is not being
maintained.  Once maintainers are in place, we can trust those guys to
do the right thing most of the time and not subject them to lots of
cross examination on every little change.

If there is a problem with getting people to volunteer, then perhaps the
first person to post a fix to a new area should get a chance to become
the maintainer for that part.  After all, they new enough to fix
something, so they have to be a reasonable choice.

Anyway, to make this approach work really well, BFAV would need to have
tags for which part of the system a bug report is associated with, and
it should be possible for people to reassign those tags.  Alternatively,
of course, we could use any existing off-the-shelf bug tracker; all of
the ones I've seen have this functionality.  Even email might work
better, honestly, if we also had a swiki page listing the points of
contact for each portion of the system.

At any rate, let's please back off from trying to recruit more people to
get out of the car and push.  Let's focus on getting the engine started.

Lex



More information about the Squeak-dev mailing list