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

[John Baldwin]

On Tuesday 25 October 2005 01:20 am, 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
> authority in unilaterally backing out my commit?
> It is also port portable to define static functions early in a file,
> before they are used.

Oh wanh.  Does the code as it stands now compile ok with gcc 4.0 or is it 
still broken?  Can you at least answer that question?

Also, why is it so bad to use prototypes for static functions and then use 
them before they are defined?  A whole bunch of drivers in the tree do that 
depending on where they put their cdevsw or DEVICE_METHOD() defintions!

Also, anyone with half a brain that reads commit mail knows that rik works on 
cp(4) and cx(4), so I think that your lack-of-MAINTAINERS claim is just a 
bunch of hot air personally.  The goal here is not to be able to point at 
someone and say "look, he didn't follow the exact letter of sub-section 7 of 
rule8 !!!!", the goal is to turn out a non-suck OS in an environment via a 
rather diverse (geographic and otherwise) group of developers.  This means 
that as developers we all need to be more like the software we supposedly 
work on: strict on what we "send" (how we work with other folks), and liberal 
on what we "receive" (how we handle interactions with other folks).  Rules 
are not there for people to nitpick.  They are there to help enable us to 
achieve the end goal, but you need to evaluation actions as far as how best 
to achieve the end goal.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org