From owner-freebsd-hackers Thu Jun 3 13:45:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E5FFC14F38 for ; Thu, 3 Jun 1999 13:45:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA99845; Thu, 3 Jun 1999 13:45:05 -0700 (PDT) (envelope-from dillon) Date: Thu, 3 Jun 1999 13:45:05 -0700 (PDT) From: Matthew Dillon Message-Id: <199906032045.NAA99845@apollo.backplane.com> To: Nate Williams Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Matt's Commit status (was Re: 3.2-stable, panic #12) References: <199906031735.NAA37037@cs.rpi.edu> <199906031938.MAA99463@apollo.backplane.com> <199906032021.OAA23554@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message