Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Jun 1999 14:21:09 -0600
From:      Nate Williams <nate@mt.sri.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Matt's Commit status (was Re: 3.2-stable, panic #12)
Message-ID:  <199906032021.OAA23554@mt.sri.com>
In-Reply-To: <199906031938.MAA99463@apollo.backplane.com>
References:  <199906031735.NAA37037@cs.rpi.edu> <199906031938.MAA99463@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[
Some history: I'm not a core member (I gave that up responsibility years
ago), but I was one of the three weirdo's that started up FreeBSD back
when I had no life.  My opinions are my own, and don't reflect the core
team.  I don't know the exact reasons why the core team removed Matt's
commit priv's, but I can make some good guesses.  Regardless, I felt
this posting needed to be sent, especially since many folks in the
'peanut gallery' such as myself have followed up with their opinions.
For what it's worth, I often-times I often reflect the same kind of
development style I'm seeing in Matt, so take it for what it's worth.
(The things that most annoy you are often the same as your own
behavior.)
]


Matthew Dillon writes:

>     I have to say, though, that in order to fix these bugs I really do
>     need my commit privs back.  If people want these things fixed,
>     complain to core.  I have the time to fix the bugs with commit
>     privs, but I just don't have the time or inclination to fix them
>     without.

What's wrong with the current 'review' scheme?

>     It is just too much stress
>     keeping a patch that should be committed in a day or two on the table for
>     two weeks and then have to beg people to deal with it.

Umm, all patches should be reviewed by someone even if you have commit
privileges.  Getting commit privileges won't speed up your commits
anymore than they do today, since reviews should still be occurring.

>     I am getting 
>     wholely sick and tired of it, and I have better things to do then try
>     to maintain a pipeline of fixes that constantly get stopped up.

See above.

>     I *want* to fix these and other bugs, but I am effectively being
>     prevented from doing so because some core members freak out over
>     the speed at which I program and the amount of rewriting I
>     sometimes do.

The problem I had with you was your inability to work with others, and
your constant riding roughshod over other people's work and code w/out
fulling understanding (or caring to understand) the reasons for the
design decisions.  You were attempting to make 'FreeBSD' into
'MattBSD' from my point of view.

Case in point, John Dyson's comments explanation to the mailing list for
many of his design decisions explained to even an uninformed person like
me that some of the changes you've made were penalizing FreeBSD, not
helping it in some cases.

>     I will point out that all the rewriting I've done so far has been
                            ^^^

I'd call it 'much', since 'some' if it was wrong and hid existing bugs
and/or introduced instabilities.  Some bugs are to be expected, but IMO
some of the 'cleanups' were ill-conceived and have done very little to
add stability or reliability to the system.  (In particular, some of the
casting bugs were downright wrong, and Bruce went through and cleaned up
a number of them after the fact.)

>     to the ultimate benefit of the project in hind sight, resulting in
>     better commented, cleaner, and more reliable code and catching
>     more bugs.

'Most' of what you have done is good stuff, but unfortunately from my
point of view, you aren unable to accept the fact that 'some' of what
you are doing is not helpful and/or wanted, and it's an all-or-nothing
situation.  This is not conducive to a group project, nor to the long
term success of FreeBSD.

Yes, NFS is *MUCH* better than it was before.  Yes, many bugs have been
fixed.  But, in the process of this you made alot of people angry due to
your behavior and unflexible development style.

While this might be acceptable if you have no peers, in a group of peers
this doesn't work.  No-one likes a lone-ranger who no-one else can work
with, and that is the kind of impression that your behavior left in my
mind.  And, this isn't the kind of behavior that will benefit FreeBSD
IMO.

Again, these are my *opinions*, based on my observations that took place
during his 'commit' status.  I have a personal desire to see FreeBSD
succeed I consider it partly 'my baby' given my long history with it.





Nate


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906032021.OAA23554>