Hi lex

We are all volunteers and we do a lot during our nights. And I'm sorry 
but if one person would help doug the process would go faster.  At one 
point in time I was the only harvester and I can tell you that when 
marcus joined it was a great feeling.

Lex my main point is that if somebody payed to code in Squeak would 
spend 1 hour every three days
then this would make a big boost.

So I disagree with you, steven cannot say we need shorter iteration 
cycles, stabler versions and not participate. There are certainly some 
problems with the current process but it starts to work.
Now we have to improve it this is clear, but without BFAV we would be 
nowhere right now. (Thanks for all the people that are working to 
improve it. This is really important).
I remember the SqueakC time where not funny, cool compiler fixes where 
simply lost (certainly because of time problems too).

I think that for example a Guide for eToy and Multimedia is NEEDED. I 
was discussing this issue off-line with the other guides. Now if you 
find a guru in each the part of Squeak then this is clear that the 
current process is not efficient enough still having another person 
browsing your code is always good.
At least for me I really appreciate that someone have a look at my 
fixes because sometimes I'm idiot, tired, or thinking to something 
else.

Stef


u wrote:

> =?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
>