Re: [TCLCORE] Upgrade of Tcl's String Hash Algorithm

[Colin M. <co...@ch...>]

Larry McVoy wrote:
> I wanted to (briefly) touch on process.  After a lovely discussion
> on #tcl it seems like it might be worthwhile to point out the 
> value of a review process.  I think that you especially may 
> appreciate the benefits.
>   

Reading your email, I'm moved to investigate the connection between 
'review' and 'review process'.  You argue cogently for code review, but 
nowhere for code review process.  You treat as synonyms what are clearly 
not.

Nobody would dissuade a person from reviewing open source code.  No 
'process' is required:  you get a copy, you study it, it's reviewed.  
But that's not what 'review process' means.

Half of your email, Larry, extols the virtues of code review.  The rest 
insinuates that since it's such a good thing, people should be forced to 
do it.

> Reviews are not for beating people up.  If people need beating that
> is best done in private.
> Reviews are somewhat good at catching problems.  That's what people
> think they are for.
> Reviews are for educating other people.  That's what people forget.
>   

Reviews are great, evidently, but what has this to do with process?  
Isn't what you call 'process' really just a nice way of saying 'obligation?'

> IMHO, if this sort of thing went through a review process
>   

See how the word 'process' creeps back into a discussion of the merits 
of review as if they were the same thing?

>     - you would get more strokes for taking on this problem
>     - at least the core would get educated about what you are doing
>     - maybe someone would have something useful to add
>   

That could all occur in any number of other ways.  Not merely from 
'review', and not demonstrably from any kind of 'process.'

> I agree with Colin (or anyone) if/when they say "don't slow down the
> people who are coding good stuff".  But I disagree with Colin et al
> that reviews do that.

Don't think I ever said reviews do that.  I think imposed processes do that.

> Good code reviews reward the guy doing the work,
> educate the people following along, there is pretty much no downside
> when it is done right.

If there were no downside it wouldn't have to be imposed or mandated, 
and to call coercion 'process' doesn't make it any more palatable.

Review is good when it's needed or desired and not when it's not.  And 
it's precisely when review is not needed or desired by those in the best 
position to know that 'process' reveals itself as obligation, resulting 
in wasted volunteer time and effort.

Bottom Line Time: the Tcl license explicitly states that there is no 
warranty.  This strongly implies that any onus to inspect the code for 
quality, suitability ir fitness for purpose is yours (the users.)  
Trying to foist that obligation onto the people who are giving you the 
code as a condition of your accepting it seems to me to be pretty grubby.

Colin.