Brad,

Brad Fuller wrote:
>...

>>I don't think it makes sense to thighten the process at this 
>>point. I am aware that "shit happens" with the current process.
>>
>>One simple example:  I am the one to blame to have accepted 
>>the "asPlural" changeset.
>>So, yes, dumb idea to approve that. Something like that happens.

And this is not a problem: some iteration(s) and all are happy.

> 
> 
> One point to make here is that with a few safeguards, there wouldn't be
> anyone to "blame". The proper process in the right setting would make sure
> this doesn't happen.

How should this work? What do you mean with a few safeguards (there are
already some of them in the actual process)?

> It doesn't mean that people can't have fun or that it
> isn't agile. But, it could mean that Squeak would grow and be more
> recognized and used by others. 
>  
> 
>>But what's the alternative? Even with the "only one 
>>harvester" rule, we don't manage to do *anything*
>>  at all. Just look at BFAV: The amount of unreviewed stuff 
>>is growing. 
>>If we now require a real formal
>>process beyond what we have now, I fear that nothing will 
>>happen. (I actually would call the current state of progress 
>>"nothing" already).
> 
>

> Quality shouldn't be reduced because the queue gets bigger. 

But if it's too difficult to review fixes, the quality will be reduced,
since only a few fixes come through the bug fixing process then at all...

It's better to have some fixes with good quality than one or none with
super duper very mostly good one.

Recently I've made a review with comments and a further iteration, and I
can say: this is hard work beside the bug fixing process!
And it takes some time to start reviewing at all (you have to read some
docs to understand how it should work).
If you like you can try it...

I think currently the slowness of the process hinders quality in the
first place...


Greetings
Stephan

>...