cvs commit: src/sys/dev/cp if_cp.c

[Sam Leffler]

Roman Kurakin wrote:
> David O'Brien wrote:
> 
>> On Mon, Oct 24, 2005 at 10:34:25AM -0400, John Baldwin wrote:
>>  
>>
>>> On Monday 24 October 2005 03:24 am, David O'Brien wrote:
>>>   
>>>
>>>> On Tue, Sep 27, 2005 at 04:57:45PM +0000, Roman Kurakin wrote:
>>>>     
>>>>
>>>>> rik         2005-09-27 16:57:45 UTC
>>>>>  FreeBSD src repository
>>>>>  Modified files:
>>>>>    sys/dev/cp           if_cp.c
>>>>>  Log:
>>>>>  Restore if_cp.c 1.27
>>>>>       
>>
>> ...
>>  
>>
>>>> You should not have backed out my commit without discussing it with me
>>>> and understanding the reason for the change.
>>>> Do it again and I *will* be taking it Core.
>>>>     
>>>
>>> Looks like he added some function prototypes and moved the cdevsw 
>>> up.  Does i compile now with gcc 4.0?  It seems that his changes were 
>>> a lot simpler and didn't destroy nearly as much CVS history as your 
>>> changes.  It would really be preferable to use simpler solutions 
>>> rather than destroying version history with really big diffs.
>>>   
>>
>>
>> Doesn't matter -- it was a clear back out of my recent commit.
>> src/MAINTAINERS doesn't list any of these drivers, so what was his
>>  
>>
> I do not want to list them in src/MAINTAINERS cause I think it is better 
> to allow any commits.
> Cases such this one is rare.
> 
> Since I didn't get reply from you within a week and I do not like 
> function relocation and didn't
> find explanation from commit log I've backout function relocation, not 
> fix of forward variable
> declaration.
> 
> The commit log didn't state what was the problem variable forward 
> declaration or/and function
> forward declaration.
> 
> rik
> 
>> authority in unilaterally backing out my commit?
>> It is also port portable to define static functions early in a file,
>> before they are used.

Roman, I very much agree with your view on maintainership--when someone 
is given commit privileges we should trust them to commit changes to any 
piece of the system.  If they are not certain their change is good 
and/or correct then they should get review (and in many cases review is 
a good habit regardless).  There have been a spate of changes of the 
above sort that go against this tenet.  It's made me stop working on 
freebsd and I suspect the continued practice will make others find a 
different place to spend their time.

	Sam