Al Hopper wrote:
> On Fri, 1 Jun 2007, Keith M Wesolowski wrote:
>
>> On Fri, Jun 01, 2007 at 04:59:42PM -0500, Al Hopper wrote:
>>
>>> Please don't ask an unpaid, volunteer, OpenSolaris developer to make
>>> changes that are simply stylistic or (personal) preference based.
>>> Consider that Sun employees are paid to make any changes their
>>> management requests - but that simply can't apply to volunteers like
>>> Roland who have already put *hundreds* of unpaid man-hours into a
>>> project.
>>
>> He's not asking Roland to make changes because he's his manager and
>> can tell him what to work on.  The correct way to interpret this is as
>> an exchange of review commentary between peer engineers.  If Roland
>> doesn't want to make those changes, Meem can ask the C-team to block
>> his RTI due to unsatisfied review comments.  That's not the same as
>> saying that Roland has to do this or that or he's fired.
>
> But if Meem can checkout the file and make the changes in less time 
> than it takes him to write the review comment - does it make sense for 
> him (and every other reviewer) to write a seemingly endless set of 
> change requests?
>
Since this is seems to be the crux of your argument, let me respond to it.

This is an inappropriate approach for a couple of reasons:

a) There may be reasons why Meem is wrong.  Roland needs to respond, 
because he may have strong reasons that Meem isn't aware of.  (I'm not 
saying that's the case here, just that it _could_ be in general.)

b) If reviewers made these changes for coders, then the coders will not 
feel obliged to learn from the event; so code review is as much about an 
exchange of information as it is about fixing the code.

c) If reviewers fix nits on behalf of coders, then why would original 
coders feel compelled to write nit-free code in the first place?  
Ultimately, this would lead to a degradation in quality, and increase 
the burden on reviewers.  (Increased burden because of impact on future 
reviews, not just one.)

I think Meem and Roland are handling this responsibly... and I don't 
think your suggestions for a change in the process are in the best 
interests of the project.

    -- Garrett


Reply via email to