Date: Thu, 03 Jun 1999 13:30:27 -0700 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Matt's Commit status (was Re: 3.2-stable, panic #12) Message-ID: <199906032030.NAA01227@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 03 Jun 1999 14:21:09 MDT." <199906032021.OAA23554@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? The review-and-commit process is too slow. That much was clear from reading the original post. > 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. The issue that you're missing here Nate is that Matt is still on the learning curve. Expecting him to come in as the "perfect" team member is foolish, and it was largely unrealistic expectations on the part of -core and other bearded regoliths that led to Matt's original ejection. > > 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.) These are hardly grounds for ejection, nor were any of Matt's other design issues. You're putting a very rosy cast on history if you claim there there's no precedent for _working_with_ problems like this. > > 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. Well shit, we've lived with it from other people before, and worked with them to the good of all. Why can't we do it here? If it's "too hard" for the old guard, I think that's a sign to them they ought not ignore. The bottom line is this: Beggars cannot be choosers. Matt represents a very valuable development resource; one which we wish to avail ourselves of. If this requires some effort on our part, eg. training Matt, learning to deal with his style, etc. this can be done. It's been done before, to fail to do it again would be proof positive of the final ossification of our "leadership", and opens the entire can that was (poorly) closed around the beginning of this year. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.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?199906032030.NAA01227>