Date: Thu, 3 Jun 1999 13:45:05 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Nate Williams <nate@mt.sri.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Matt's Commit status (was Re: 3.2-stable, panic #12) Message-ID: <199906032045.NAA99845@apollo.backplane.com> References: <199906031735.NAA37037@cs.rpi.edu> <199906031938.MAA99463@apollo.backplane.com> <199906032021.OAA23554@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 addressed these. Re-read my message. Personally I think reviews are
fine, but I will also point out that nearly all the commits done in the
last few weeks have not been reviewed with any seriousness prior to the
fact as far as I can tell. The combination of being forced to have
someone to review even minor fixes and then have to spend another week
waiting, praying, and begging for it to get committed is too long and
too stressful. I have had little success with people reviewing my stuff
anyway -- the only people who understand it take days to review it and
I get the feeling that they do not spend all that much time at it even
when they do review it. It might as well not be a review at all.
: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.
This couldn't be further from the truth. It is a misconception that
many people have because I bring up alternatives for discussion. Most
of those alternatives are just for discussion, *not* something I've
actually implemented and committed. People also freak out when I spend
an hour to implement something (without committing it) in order to test
its viability. They seem to believe that I intend to commit it. But
people seem to ignore the part of my email that says something is just
for test, or just a possible solution and then seem to believe that
the algorithm or item has been committed when, in fact, it was never
intended to even be written.
Find one thing that I've committed that you believe there was serious
resistance to on algorithmic grounds. One thing, and I'll tell you the
story behind it. I've made dozens of changes and I've rewritten bunches
of stuff. What mistakes I have made have been unintentional -- for
example, when we broke the buffer cache performance on writes. That
breakage was not due to the algorithmic rewrite on algorithmic grounds,
but instead due to two lines of missing code. But rather then actually
look at the code closely all I got from one core member was a stupid ass
posting gushing with inuendo and blame. A screaming fit over two lines
of missing code. Ridiculous!
: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.)
Like what? Many of the cleanups I did located EXISTING misimplementations
elsewhere. These were not bugs in my commits, but bugs elsewhere in the
code. I have to fuckup the system anywhere near as badly as other people
have in the last few months, yet I do not hear massive complaining about
them!:
Case in point: Pages on the PQ_CACHE are not supposed to be dirty. When
I committed assertions to ensure this ( after almost a week of testing, I
might add ) and some people started reporting crashes, it exposed a
*SERIOUS* bug in older code (not my code!) that I had nothing to do with.
That bug was probably responsible for any number of serious corruption
panics in the past.
That commit was appropriate. Would argue that it wasn't because
it caused a panic? So then you would be arguing that the system was
in better shape by not following its own spec then by following it?
People, in general, seem afraid to add assertions to the code. This
is stupid. Assertions are the quickest way to bring out and isolate
bugs that you may not even have known existed. I put over a half a dozen
major assertions in the VM code and found a large number of bugs that way.
The result? The VM code is an order of magnitude more solid now then
it was at the beginning of the year, let alone when compared against
2.2.7 before the MFCs started rolling in. It is the difference between
night and day! Those assertions made it possible.
: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, this couldn't be farther from the truth. The keyword is "Peers".
When I first got my commit privs, half of core decided to stomp all over
me with decrees, many of which were no more then thinly disguised insults
(whether on purpose or not). Not interact with me as a peer.
I attempted to interact with those people as a peer, but the same
consideration was not returned to me. Fortunately that wasn't everyone.
There are people in core who are willing to take things at face value
and interact as peerage. Probably most people in core. But you never
hear the good side of things, only the bad spill over into the groups.
:Nate
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199906032045.NAA99845>