Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
dro...@rpi.edu said: :- While others seemed too busy with new technology to bother with :- ugly-old-NFS problems, Matt dived in and pursued them with enough :- enthusiasm to make a real difference. In particular, lots of NFS bugs that had been there, and reported, since early 2.2 days. Bugs that made it impossible for me to agitate for FreeBSD boxes to replace the hundreds of Sun workstations at my site, cuz NFS would just fall over dead. I don't care even if Matt smells like a pig. He's a-fixin bugs, don't ye know? - Robert Withrow, R.W. Withrow Associates, Swampscott MA, w...@rwwa.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On Wed, 16 Jun 1999, Robert Withrow wrote: dro...@rpi.edu said: :- While others seemed too busy with new technology to bother with :- ugly-old-NFS problems, Matt dived in and pursued them with enough :- enthusiasm to make a real difference. In particular, lots of NFS bugs that had been there, and reported, since early 2.2 days. Bugs that made it impossible for me to agitate for FreeBSD boxes to replace the hundreds of Sun workstations at my site, cuz NFS would just fall over dead. I don't care even if Matt smells like a pig. He's a-fixin bugs, don't ye know? I really can't get too excited over a bunch of folks who continually open threads that are painful, that have been explained in horrible detail, as if they have some new viewpoint. It was done for very good reasons, although we didn't ask your permissions, and it wasn't kept a secret (except maybe that no one wanted to embarrass Matt). Either go back to the mail archives and *find out* why it was done, or please do everyone involved a service and stop this. There isn't any conspiracy here, sorry! +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Jordan K. Hubbard wrote: Excellent. Let's assume then that all the core folk who are there, plus any committers who have an interest in the issue (since core has to listen to its developers' opinions too or we can no longer honestly claim to represent their interests), will be getting together during the week to discuss this issue along with perhaps some general technical discussion of your work and your future plans. It would be a shame (not to mention stupid) to waste this opportunity. For the benefit of those of us who weren't at USENIX, can we please have a summary of what was discussed/decided? -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
For the benefit of those of us who weren't at USENIX, can we please have a summary of what was discussed/decided? Nothing was [deliberately] decided but much was discussed. As soon as one of us lands back home in some reasonable state, a summary will be posted. I've yet to do this myself and will be on the road for the rest of the week as well. :| - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
For what it's worth, and to throw another hat into the fray, it seems to me that two things are driving the tension here: 1) Matt is effectively in a position where he no longer has to work, and can now dedicate a significant amount of focussed effort over long intervals at FreeBSD code. 2) The review process currently in force requires review by people who do not have such a luxury of time in which to review the code Matt produces; stated simply: they can't keep up. Having been in a similar position, where an employer was having me spend 8 hours a day working on filesystem code, the changes to which were 85%-90% applicable to FreeBSD, I can sympathize with Matts position. As FreeBSD becomes more and more mainstream (some of you may have heard about IBM's recent acquisition of Whistle, or their bid for FreeBSD based machines to school districts in Hong Kong: that's about as mainstream as FreeBSD can get), the number of people with an equivalent of Matts available time and energy to focus on FreeBSD coding can only increase. I don't know the simple answer to the dilemma posed by FreeBSD's increasing success; however, it is clear to me that there is a need to look for such an answer, and to find one -- the sooner the better. Perhaps all of you can discuss this issue at the FreeBSD BOF at Usenix. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
For what it's worth, and to throw another hat into the fray, it seems to me that two things are driving the tension here: 1)Matt is effectively in a position where he no longer has to work, and can now dedicate a significant amount of focussed effort over long intervals at FreeBSD code. 2)The review process currently in force requires review by people who do not have such a luxury of time in which to review the code Matt produces; stated simply: they can't keep up. Having been in a similar position, where an employer was having me spend 8 hours a day working on filesystem code, the changes to which were 85%-90% applicable to FreeBSD, I can sympathize with Matts position. I can also. Software developers and engineers are NOT interchangeable though. Therefore, the various skills and abilities don't always match the needs... IMO, the best thing that can effectively be done is to continue the way things are going, until appropriate people can be available to keep the pipeline full. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Matthew Dillon said: I don't want to be a pest, because this really shouldn't be on an open forum. But John: I would ask you questions and the answers I would get would be in the form: Nobody understands that code but me, don't touch what you don't understand, or The algorithm is obvious from the code. This in regards to non-compartmentalized algorithms strewn across half a dozen source files which are almost universally lacking in comments of any substance. The frustration that I was showing was a result of off the wall assertions being made, with few coherent questions. Your questions are often analogous to someone saying that the VM code sucks, but will you help me with it, by teaching it to me? Oh, by the way, I haven't read the docs that you asked me to... :-). Hows about the frustration of being asked to review code corrections (or even seeing commits) that show a confusion that would have been cleared up if the docs were read, and then time was spent to ask questions that are backed with some initial understanding? That VM code was very fragile. It mostly worked, but it was very fragile. It still IS fragile. Are you trying to assert that the code is broken, and you will come in on your white horse and fix it? The minor fixes that should really be done are little in comparisons with the complexities and work associated with the original innovation. Actually, there is alot in the (VM) code that causes it to be generally robust. It is important to make sure that the code is well understood, or the various mechanisms that do provide for robust behavior in various loading conditions will be broken. (Randomly changing code that the hacker doesn't understand will indeed make code appear to be fragile.) The VFS code does need work, but it should be done only if the reasons and effects of its design are well understood by the individuals doing the work. There is a lot of infomation available, and it is available for the asking. The interface to filesystems and how they work need to be done from scratch. The need for backwards compatibility is probably gone now, and has been less important after the softupdates being integrated. There are two significant approaches to fixing the interface, and my suggestion is to eliminate the block-buffer interface all together. That was on my list, and really would have taken only a few weeks of work (and alot of review and testing.) I suggest design consultation before design and implementation however. Note that there are alot of individuals with biased views as to how to do I/O, and some of them have really good ideas. The key is to integrate what is needed for the I/O subsystems, and what is needed for filesystems. The caching per-se is already handled architecturally, so almost any work on vfs_bio beyond minor fixes for NFS are probably wasted effort on a legacy design that is less efficient than need be. On of the original passes for the merged VM buffer cache eliminated the buffers except for metadata, and the scheme worked. Since the need for backwards compatibility is almost gone, totally eliminating the buffer cache (and associated metdata bp-buffers) would be a good project. By elimintaing VFS_BIO, 99% of the grunge code would be eliminated from the VM/VFS code. Most of the ugliness in the VM code is there in order to interoperate with filesystems, and the methods used for them. If the vfs_bio rework is done, and done properly, the issues of coherency with VM and across VFS layers will be very clean to implement. In essense, this would be a forward moving project, which would avoid massive amounts of rework, and minimize breaking existing code. I suspect that re-architecting vfs_bio would be the best possible time investment. Continual re-working of the code, when it is used in ways that it wasn't even architecturally designed for (e.g. NFS, LFS), is more of an exercise in continual polishing. Note that the architectural issues regarding vfs_bio and NFS appeared way before the FreeBSD code, but have been problematical from day one. Note all of the hackery in the NFS code to make the buffer cache paradigm sort-of work... LFS is yet another beast that has work arounds to support a buffer cache scheme. Someone who wants to do something creative, with a user population that would be very thankful and that person wants to work on VM or VFS code, will consider carefully the straightforward effort to redesign VFS_BIO. If you want, I can have a working copy for you in a couple of weeks!!! :-). -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On Sat, 5 Jun 1999 03:24:07 -0500 (EST) John S. Dyson dy...@iquest.net wrote: I don't want to be a pest, because this really shouldn't be on an open forum. But John: I would ask you questions and the answers I would get would be in the form: Nobody understands that code but me, don't touch what you don't understand, or The algorithm is obvious from the code. This in regards to non-compartmentalized algorithms strewn across half a dozen source files which are almost universally lacking in comments of any substance. The frustration that I was showing was a result of off the wall assertions being made, with few coherent questions. Your questions are often analogous to someone saying that the VM code sucks, but will you help me with it, by teaching it to me? Oh, by the way, I haven't read the docs that you asked me to... :-). Hows about the frustration of being asked to review code corrections (or even seeing commits) that show a confusion that would have been cleared up if the docs were read, and then time was spent to ask questions that are backed with some initial understanding? I dunno, John. Matt's right on the ball here, from my experience. Vague non-answers seem to be your specialty. -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On Sat, 5 Jun 1999 03:24:07 -0500 (EST) The frustration that I was showing was a result of off the wall assertions being made, with few coherent questions. Your questions are often analogous to someone saying that the VM code sucks, but will you help me with it, by teaching it to me? Oh, by the way, I haven't read the docs that you asked me to... :-). Hows about the frustration of being asked to review code corrections (or even seeing commits) that show a confusion that would have been cleared up if the docs were read, and then time was spent to ask questions that are backed with some initial understanding? I dunno, John. Matt's right on the ball here, from my experience. Vague non-answers seem to be your specialty. Rude, snide comments seem to be yours. I'm sorry that I haven't given you answers to every question that you might have asked, but I doubt that the motivation of your questions were in the best interests of everyone involved. The only way that I can reasonably give answers to questions is if the answer is really wanted. This is a continual problem where if I give an answer, it is often begged with another question that often shows that the real answer isn't desired. Almost anyone who as really asked me for help, and really wants the answer has gotten the answer. One good way to determine if an answer is really desired is to find out if the person who poses the question is willing to research the publically existant information (often the information is out in the open, and indexed in publically available databases.) Questions are often asked when the info is already out there -- it is always best to show people how to get their own answers. The best way that I can generally add to the information out there is to request that people call me, or if specific questions are asked after some effort in doing the research has be made. Sometimes questions are asked, and the correct answer isn't the one that is desired, and then the question is asked again to see if the answer has changed... Seldom do I need to change my answer, unless the question is different :-). John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Jason Thorpe wrote: I dunno, John. Matt's right on the ball here, from my experience. Vague non-answers seem to be your specialty. That appears to be a comment designed to create a flame war. It certainly is not helpful to FreeBSD. Please don't abuse our lists. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Matt's Commit status (was Re: 3.2-stable, panic #12)
[ 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
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. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
: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
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Perhaps we can cut through all the finger pointing and counter-finger pointing here and just move on to the chase by asking one simple question: Will you be at USENIX? That would be an excellent opportunity to discuss it in person, where emotion and facial-expression stripping isn't such a huge problem and we can also discuss the matter with far greater bandwidth. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
:Perhaps we can cut through all the finger pointing and counter-finger :pointing here and just move on to the chase by asking one simple :question: Will you be at USENIX? That would be an excellent :opportunity to discuss it in person, where emotion and :facial-expression stripping isn't such a huge problem and we can also :discuss the matter with far greater bandwidth. : :- Jordan Yes, I will be at USENIX. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Excellent. Let's assume then that all the core folk who are there, plus any committers who have an interest in the issue (since core has to listen to its developers' opinions too or we can no longer honestly claim to represent their interests), will be getting together during the week to discuss this issue along with perhaps some general technical discussion of your work and your future plans. It would be a shame (not to mention stupid) to waste this opportunity. - Jordan :Perhaps we can cut through all the finger pointing and counter-finger :pointing here and just move on to the chase by asking one simple :question: Will you be at USENIX? That would be an excellent :opportunity to discuss it in person, where emotion and :facial-expression stripping isn't such a huge problem and we can also :discuss the matter with far greater bandwidth. : :- Jordan Yes, I will be at USENIX. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
At 2:08 PM -0700 6/3/99, Jordan K. Hubbard wrote: Excellent. Let's assume then that all the core folk who are there, plus any committers who have an interest in the issue (since core has to listen to its developers' opinions too or we can no longer honestly claim to represent their interests), will be getting together... I'm not on the core, I'm not a committer, and I won't be at Usenix. Still, I'd like to mention that as a freebsd *user*, I have appreciated the recent NFS-related work that Matt has done. While others seemed too busy with new technology to bother with ugly-old-NFS problems, Matt dived in and pursued them with enough enthusiasm to make a real difference. Even though we obviously still have a few more NFS bugs bothering us, just the fact that someone is obviously pursuing them makes those of us who use FreeBSD for NFS-serving feel much better. Someone who has this much spare energy for tracking down ancient problems in technologically-uninteresting code should be getting some reward for it. In a project like this, it seems to me that the standard reward is a certain degree of respect, and I think Matt's recent work has earned him a bit more respect than he seems to be getting. Given that the FreeBSD project sees one of it's strengths as being a server OS, it baffles me that someone working hard to improve the stability of that OS is being treated as an 'outsider' by the core of 'insiders'. It's not that I think the current insiders are doing bad work, it's just that we can always use someone willing to track down obscure bugs in boring and ancient code. That's just my view as one FreeBSD user. --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
I second this. Even if it's a bit painful, somebody who has been working diligently at this needs to be able to be make their work usable quickly. I would guess that not too many things hinder progress, or quash desire more than fixes to problems languishing. There has to be some middle ground somewhere that lets Matt get his fixes in quickly, and still doesn't ruffle too many core feathers. I had the opportunity to hear some of the core side recently, and I certainly sympathize or empathize with the issue, but nobody else has stepped up to fix the NFS problems, and I would like to see this opportunity capitalized on. On Thu, 3 Jun 1999, Garance A Drosihn wrote: At 2:08 PM -0700 6/3/99, Jordan K. Hubbard wrote: Excellent. Let's assume then that all the core folk who are there, I'm not on the core, I'm not a committer, and I won't be at Usenix. Still, I'd like to mention that as a freebsd *user*, I have appreciated the recent NFS-related work that Matt has done. While others seemed To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On 03-Jun-99 Jaye Mathisen wrote: I second this. Even if it's a bit painful, somebody who has been working diligently at this needs to be able to be make their work usable quickly. I would guess that not too many things hinder progress, or quash desire more than fixes to problems languishing. There has to be some middle ground somewhere that lets Matt get his fixes in quickly, and still doesn't ruffle too many core feathers. I had the opportunity to hear some of the core side recently, and I certainly sympathize or empathize with the issue, but nobody else has stepped up to fix the NFS problems, and I would like to see this opportunity capitalized on. Not knowing the FULL story from both sides, I feel it'd be inappropriate if I were to comment on it. However knowing Matt's coding abilities, having seen the eruption here a few months ago, and the past splits that IIUC were due to core problems, perhaps an oversight board (for lack of a better description) consisting of zero core people and zero committers may help to stop or solve some of these erruptions before they spill out into the public's view. Who does a coder, committer, core member, etc, have to turn to if (s)he feels (s)he's getting the shaft? Not anything aimed at you (Jordan) or David, but let's face it - you two have enough to do without having to worry about the petty crap that seeps out as well. Vince. -- == Vince Vielhaber -- KA8CSH email: v...@michvhf.com flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
It is a nice idea and I have proposed it in the past however most likely such organization will devolve to the current status-quo with core;however, if the oversight committee is composed of individuals from companies using FreeBSD it may actually work for committee should have a vested interest in FreeBSD. Vince Vielhaber wrote: On 03-Jun-99 Jaye Mathisen wrote: I second this. Even if it's a bit painful, somebody who has been working diligently at this needs to be able to be make their work usable quickly. I would guess that not too many things hinder progress, or quash desire more than fixes to problems languishing. There has to be some middle ground somewhere that lets Matt get his fixes in quickly, and still doesn't ruffle too many core feathers. I had the opportunity to hear some of the core side recently, and I certainly sympathize or empathize with the issue, but nobody else has stepped up to fix the NFS problems, and I would like to see this opportunity capitalized on. Not knowing the FULL story from both sides, I feel it'd be inappropriate if I were to comment on it. However knowing Matt's coding abilities, having seen the eruption here a few months ago, and the past splits that IIUC were due to core problems, perhaps an oversight board (for lack of a better description) consisting of zero core people and zero committers may help to stop or solve some of these erruptions before they spill out into the public's view. Who does a coder, committer, core member, etc, have to turn to if (s)he feels (s)he's getting the shaft? Not anything aimed at you (Jordan) or David, but let's face it - you two have enough to do without having to worry about the petty crap that seeps out as well. Vince. -- == Vince Vielhaber -- KA8CSH email: v...@michvhf.com flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On 03-Jun-99 Amancio Hasty wrote: It is a nice idea and I have proposed it in the past however most likely such organization will devolve to the current status-quo with core;however, if the oversight committee is composed of individuals from companies using FreeBSD it may actually work for committee should have a vested interest in FreeBSD. My thoughts actually extended beyond oversight committee and into a sort of an appeals role. As far as who, 'individuals from companies' may not provide a broad enough scope. But they should definitely have a vested interest - and no legal degree :) Vince. -- == Vince Vielhaber -- KA8CSH email: v...@michvhf.com flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
[I rearranged the things since these folks can't be bothered to comment at the bottom] Vince Vielhaber wrote: Not knowing the FULL story from both sides, I feel it'd be inappropriate if I were to comment on it. However knowing Matt's coding abilities, having seen the eruption here a few months ago, and the past splits that IIUC were due to core problems, perhaps an oversight board (for lack of a better description) consisting of zero core people and zero committers may help to stop or solve some of these erruptions before they spill out into the public's view. Who does a coder, committer, core member, etc, have to turn to if (s)he feels (s)he's getting the shaft? Not anything aimed at you (Jordan) or David, but let's face it - you two have enough to do without having to worry about the petty crap that seeps out as well. Vince. On Thu, 3 Jun 1999, Amancio Hasty wrote: It is a nice idea and I have proposed it in the past however most likely such organization will devolve to the current status-quo with core;however, if the oversight committee is composed of individuals from companies using FreeBSD it may actually work for committee should have a vested interest in FreeBSD. I'm sorry, these are both crack-pot ideas, it's been explained again and again, and Amancio, for one, knows this, so I can't see why he went on this way. I will restate the obvious again, please read this before exploding, because I'll make it real clear. I am going to explain reality; if you're complaining about reality, go grab a bottle of bourbon, it will work as well. Reality: FreeBSD is written (not run, not administered, really written) by volunteers. These volunteers work on what they want to. Core can say NO, but they can't say YOU WILL, because the volunteers WON'T. People with no intention (and often no ability) to code keep wanting to tell the folks that DO code what to do. Impossible, this IS NOT a paid organization, the volunteers will just go away and code for another group that is less self-desctructive. Some group you're talking about that doesn't code has no authority whatsoever, and in fact no expertise at all to even pretend they know what they're doing, else they WOULD be coding. You cannot code without real experience, this is not some weird TV show with scifi unreality. The only group that these volunteers will listen to or respect is a group of folks that DO code and DO have the expertise. Trying to get together a group of dilettantes may be a marketing man's idea of how to go, but it will not fit FreeBSD's reality, and you cannot force things like that here. Just realize, IF you're loud enough, and succeed, the programmers will all desert you, and you'll have a nice place to argue, but no more software. Core here does an excellent job, with all the problems they face, most committers will agree to that pretty quickly, and they are the only ones with a vote. Look to reality for the reasons why. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On 04-Jun-99 Chuck Robey wrote: [I rearranged the things since these folks can't be bothered to comment at the bottom] Vince Vielhaber wrote: Not knowing the FULL story from both sides, I feel it'd be inappropriate if I were to comment on it. However knowing Matt's coding abilities, having seen the eruption here a few months ago, and the past splits that IIUC were due to core problems, perhaps an oversight board (for lack of a better description) consisting of zero core people and zero committers may help to stop or solve some of these erruptions before they spill out into the public's view. Who does a coder, committer, core member, etc, have to turn to if (s)he feels (s)he's getting the shaft? Not anything aimed at you (Jordan) or David, but let's face it - you two have enough to do without having to worry about the petty crap that seeps out as well. Vince. On Thu, 3 Jun 1999, Amancio Hasty wrote: It is a nice idea and I have proposed it in the past however most likely such organization will devolve to the current status-quo with core;however, if the oversight committee is composed of individuals from companies using FreeBSD it may actually work for committee should have a vested interest in FreeBSD. I'm sorry, these are both crack-pot ideas, it's been explained again and again, and Amancio, for one, knows this, so I can't see why he went on this way. I will restate the obvious again, please read this before exploding, because I'll make it real clear. I am going to explain reality; if you're complaining about reality, go grab a bottle of bourbon, it will work as well. Reality: FreeBSD is written (not run, not administered, really written) by volunteers. These volunteers work on what they want to. Core can say NO, but they can't say YOU WILL, because the volunteers WON'T. People with no intention (and often no ability) to code keep wanting to tell the folks that DO code what to do. Impossible, this IS NOT a paid organization, the volunteers will just go away and code for another group that is less self-desctructive. Some group you're talking about that doesn't code has no authority whatsoever, and in fact no expertise at all to even pretend they know what they're doing, else they WOULD be coding. You cannot code without real experience, this is not some weird TV show with scifi unreality. The only group that these volunteers will listen to or respect is a group of folks that DO code and DO have the expertise. Trying to get together a group of dilettantes may be a marketing man's idea of how to go, but it will not fit FreeBSD's reality, and you cannot force things like that here. Just realize, IF you're loud enough, and succeed, the programmers will all desert you, and you'll have a nice place to argue, but no more software. Core here does an excellent job, with all the problems they face, most committers will agree to that pretty quickly, and they are the only ones with a vote. Look to reality for the reasons why. No need for blowing up, so relax. You may wanna grab that bourbon bottle yourself and take a sip. 1) Noone ever said anything about marketing types trying to run anything. 2) Nothing was ever said about telling volunteers what to do or not do. 3) Nothing was mentioned about the technical abilities of an appeals board or oversight group. 4) Ever do or say something that someone told you that you're out of line? 5) Let's go back to your volunteer thing. You have volunteers willing to work for you - for free. It's no secret that in the past core has been a problem for some (or maybe even many) of these volunteers. They went away. If there's noone they can go to, why should they (or anyone else) bother to volunteer? Earlier in this thread Matt was accused of running rough shod over everyone. Looking over the history and hearing the complaints of some of those involved, I admit not knowing both sides of the FULL story, that core may be partially to blame. But who is there for the *VOLUNTEERS* to turn to? Core? They may have caused the problem. Then once the emotions start to rise there's absolutely NOONE for any of them to look to besides Jordan and/or David. Like they don't already have enough to do. It's obvious there's a problem with the status quo, but if the status quo continues to run rough shod over any possible solution, status quo will end up running out of volunteers and there will be yet another BSD to add to the collection. Maybe the next one can be called ClosedBSD? Now reread your own last paragraph. It goes at least two ways. How much talent and support (technical, financial, advocational[1], etc.) are you willing to lose before anyone's told they're outa line? For all that matter, how much has already been lost? You used the phrase crack pot. Doesn't a cracked pot leak? Isn't that what's already happening? Talent leaking out? Vince.
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Nate Williams said: 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. BTW, my frustration was due to the strong assertions being made with no qualification as to them being preliminary. It was made worse due to the offers that I had made (and in fact supported) to help correct the misunderstandings before the assertions were made publically, or code was being committed. If code is being committed, then it is difficult to assume that the code is only preliminary. Preliminary at the level of the sometimes misunderstanding was pre-alpha in quality, and probably not appropriate for commits. Finally, the frustration level got to the point of overflowing. Recognizing the learning curve is maybe being made in hindsight. If the individual who was in the learning phase would have acknowledged or admitted it to themselves at the time, the needed questions would have been asked by them to clarify their misunderstanding (and sometimes my understanding was wrong also -- however there was a very strong assertiveness that seemed to make it difficult for me to overcome.) Note there were significant commits made without the sometimes incorrect assertions being checked. In fact, some commits were made while those assertions were currently challenged, and in some cases found to be incorrect. Not all of the assertions that were made were incorrect, and in *some* cases I was wrong. However, the inability to accept a challenge caused severe tension. I didn't have lots and lots of time to review the claims, and sometimes I had to give hints as to the needed fixes. There were some assumptions made about the complexity of the code, and those assumptions about it were often (but not always) wrong. If the questions were asked in the form how does this work? instead of this is wrong, and I have a fix then there would have been few problems. Of course, in many cases, the statement that this is wrong was incorrect, because the question how does this work? wasn't often asked. The learning curve would have been much less painful if questions would have been asked and/or the answers weren't ignored. (There were cases of my answers and suggestions not even being challenged, but were rejected out of hand.) After a while, the *only* way to be heard was to become extremely assertive. Being assertive the way that I had to be was very very painful for me, but regressions kept on creeping in. The *only* way to throttle the anti-progress was to raise a big stink. As an artifact of hindsight, it might be possible to currently spin the situation as being a difficult learning curve, but the fact was that the learning curve didn't have to be difficult, and the tools to make it easier were available, but were ignored. Since a review process is now in place, and if it is continues to be followed, then the commit privs might (IMO) reasonably be reinstated. The key is to make it a standard practice to truly understand a piece of code before making changes to it. I was upset about Matt having his privs removed, but also had mixed feelings about it due to the need to throttle some of the changes that were being made sometimes without a clear understanding of how the code being changed really works. I suspect that there are still things happening that miss the point as to how the code works, and I am still available as a resource. However, seeing code changes that are a result of ignoring either the need to carefully understand the code, or ignoring available resources caused alot of frustration. There is *nothing* that inhibits me from communicating how the code works, however the potential recipient of the info has to want to hear it. Sometimes I had to give hints rather than detailed operational info, but those hints would have mitigated enough regression to make the information worthwhile. I am sometimes slow about reviewing things (like the pipe code fixes right now), however will eventually get around to them. FreeBSD is in the phase where it needs to maintain commercial quality with less tolerance for experimental works interfering with operational behavior. The backlog of new code that I had when I quit was probably at least a year of commits. Quickly writing code and committing it (even if the code was well understood) had to stop, and it was part of my new operating procedure, esp since I was one of the more aggressive system-breaker :-). I had put together a testing framework (including people interested in getting pre-commit code to experiment with.) I suggest that that sort of infrastructure be put into place now, if there are significant new features to be added. (It isn't enough, IMO, to have code reviewed by developers, but it is wise to enlist the support of end users who are willing to try new changes on test
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
Chuck Robey wrote: [I rearranged the things since these folks can't be bothered to comment at the bottom] Vince Vielhaber wrote: Not knowing the FULL story from both sides, I feel it'd be inappropriate if I were to comment on it. However knowing Matt's coding abilities, having seen the eruption here a few months ago, and the past splits that IIUC were due to core problems, perhaps an oversight board (for lack of a better description) consisting of zero core people and zero committers may help to stop or solve some of these erruptions before they spill out into the public's view. Who does a coder, committer, core member, etc, have to turn to if (s)he feels (s)he's getting the shaft? Not anything aimed at you (Jordan) or David, but let's face it - you two have enough to do without having to worry about the petty crap that seeps out as well. Vince. On Thu, 3 Jun 1999, Amancio Hasty wrote: It is a nice idea and I have proposed it in the past however most likely such organization will devolve to the current status-quo with core;however, if the oversight committee is composed of individuals from companies using FreeBSD it may actually work for committee should have a vested interest in FreeBSD. I'm sorry, these are both crack-pot ideas, it's been explained again and again, and Amancio, for one, knows this, so I can't see why he went on this way. I will restate the obvious again, please read this before exploding, because I'll make it real clear. I am going to explain reality; if you're complaining about reality, go grab a bottle of bourbon, it will work as well. Reality: FreeBSD is written (not run, not administered, really written) by volunteers. These volunteers work on what they want to. Core can say NO, but they can't say YOU WILL, because the volunteers WON'T. People with no intention (and often no ability) to code keep wanting to tell the folks that DO code what to do. Impossible, this IS NOT a paid organization, the volunteers will just go away and code for another group that is less self-desctructive. Some group you're talking about that doesn't code has no authority whatsoever, and in fact no expertise at all to even pretend they know what they're doing, else they WOULD be coding. You cannot code without real experience, this is not some weird TV show with scifi unreality. I differ with the above Alice in Wonderland explanation on the management of coders or software projects. In your scenario I would say it depends upon whether the coders wishes to impose his own technological point of view and displace others solely based on political or emotional motivations without any technological or scientific considerations and what should be done about it when we reach such crossroads which is a far cry from dictating what people should code or do. I do understand that this is a volunteered organization and you don't need to explain it . I think that if the current scenario of core just snapping priviliges or ignoring developers continues development will actually come to a painfully slow pace. Just read Matt's email and see who is stepping up to take his place and he is a *volunteer*. The problem now is who can step up to support Matt , NFS development, or resolve the current conflict between core and Matt. As stated by another user, NFS is a key technology component for a UNIX server class OS. Amancio To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
[.] Someone who has this much spare energy for tracking down ancient problems in technologically-uninteresting code should be getting some reward for it. In a project like this, it seems to me that the standard reward is a certain degree of respect, and I think Matt's recent work has earned him a bit more respect than he seems to be getting. [.] IMHO Matt is respected far more than you think. But as he points out himself, you never get to see that respect - you just tend to get dumped on from a great height when you do anything slightly wrong - even if that wrongness is just a different way of doing things. -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@uk.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
:The learning curve would have been much less painful if questions :would have been asked and/or the answers weren't ignored. (There were :cases of my answers and suggestions not even being challenged, but :were rejected out of hand.) After a while, the *only* way to be :heard was to become extremely assertive. Being assertive the way :that I had to be was very very painful for me, but regressions :kept on creeping in. The *only* way to throttle the anti-progress :was to raise a big stink. I don't want to be a pest, because this really shouldn't be on an open forum. But John: I would ask you questions and the answers I would get would be in the form: Nobody understands that code but me, don't touch what you don't understand, or The algorithm is obvious from the code. This in regards to non-compartmentalized algorithms strewn across half a dozen source files which are almost universally lacking in comments of any substance. It would take several emails back and forth before you would grudgingly dig up your old code and review it yourself. Because you were often not absolutely sure about your own description, you tended to give me general answers lacking in detail first, requiring me to prod you for further detail. That VM code was very fragile. It mostly worked, but it was very fragile. It still IS fragile. I spent a quarter of my time simply commenting the existing code. I've had to do the same thing with the NFS and buffer cache code, VM object code, VM map code. The VFS code still needs a huge amount of commenting. The struct buf and device interaction with the struct buf still needs an enormous amount of commenting. blkno, lblkno, pblkno hack upon hack upon hack. All uncommented and inadequately commented. -Matt Matthew Dillon dil...@backplane.com :dy...@iquest.net | it makes one look stupid :jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On Thu, 3 Jun 1999, Vince Vielhaber wrote: Just realize, IF you're loud enough, and succeed, the programmers will all desert you, and you'll have a nice place to argue, but no more software. Core here does an excellent job, with all the problems they face, most committers will agree to that pretty quickly, and they are the only ones with a vote. Look to reality for the reasons why. No need for blowing up, so relax. You may wanna grab that bourbon bottle yourself and take a sip. Maybe you're right, but I'm tired to people talking about core like they're some evil overlord group. These guys are longtime FreeBSDers. They've been doing it a long time, and a large part of why they are still doing it is because of a feeling of responsibility. They're doing a great job, even if it's not 100% without error, and FreeBSD would go right down the tubes pretty quickly without coolheaded guidance, just because of the lack of control. You don't have to look hard at all to see several recent (and some ongoing) episodes of folks trying to go off on their own, and the only real restraint is the realization of what kind of limits core will allow. It's got a *great* track record. We can argue specific issues, but attacking core itself, that I'm going to jump up and shout about. 2) Nothing was ever said about telling volunteers what to do or not do. You referred to a group other than core setting policy. 3) Nothing was mentioned about the technical abilities of an appeals board or oversight group. You said that group would have no committers or core on it. Anyone who's shown skill and time has been pretty quickly asked to become a committer, so that pretty much means you're asking for either non-technical folks, or folks without the time to follow things close enough to have any real idea what's going on. Seeing as you did admit you haven't followed the issues closely enough yourself, you're one of the ones you figure would be on that board, right? 4) Ever do or say something that someone told you that you're out of line? Oh, yeah, sure, I make mistakes. Maybe wrong here, but I said above what keyed me off. It sure isn't bragging if I say here that I'm willing to bet I make more mistakes than you do, but I don't think I'm wrong here. 5) Let's go back to your volunteer thing. You have volunteers willing to work for you - for free. It's no secret that in the past core has been a problem for some (or maybe even many) of these volunteers. They went away. As has been pointed out endless times, you have to know how to code and be willing to read FreeBSD code enough so that you can contribute well integrated code. If you can't code or don't have the time, no, you can't contribute that way. You can help us by putting in problem reports, but not by trying to gain control, even a small part. The coders control FreeBSD, because they love it. Those are really the only folks who get to directly contribute. Free contributors, out of control, are a mob. If there's noone they can go to, why should they (or anyone else) bother to volunteer? The FreeBSD mailing lists are the most active, quick response groups on the net. Don't you feel silly claiming there's no one they can go to? Earlier in this thread Matt was accused of running rough shod over everyone. Looking over the history and hearing the complaints of some of those involved, I admit not knowing both sides of the FULL story, that core may be partially to blame. But who is there for the *VOLUNTEERS* to turn to? Core? They may have caused the problem. Then once the emotions start to rise there's absolutely NOONE for any of them to look to besides Jordan and/or David. Like they don't already have enough to do. That last paragraph ... core may be partially to blame. Did you read the entire thing, which went on in the -current and -committers list? If you didn't, then you don't get a chance to comment. If you want to jump on core, read the mailing list archives and get the arguments in order. You can't just slander folks that way, and expect it to be taken as just innocent sniping, because sniping isn't innocent. In fact, Matt was hearing a great deal of negative comment on his commits, from folks who originally did the code, and he was ignoring it, claiming it slowed him down. This went on over weeks. The only way to stop him, demonstrably, was what was done, because all the mail arguments did was raise temperatures, not slow things down a whit. Matt does *great* code, he just doesn't like to read and test as much as code away and react later to problem reports. Being that he was working on the virtual memory system, something which can very easily get totally beyond repair without careful testing, his refusal to slow down was more than could be tolerated. He may well write better code than nearly all of us, but he needed to do it slower. He sure as heck writes better code than I do.
Re: Matt's Commit status (was Re: 3.2-stable, panic #12)
On 04-Jun-99 Chuck Robey wrote: On Thu, 3 Jun 1999, Vince Vielhaber wrote: Just realize, IF you're loud enough, and succeed, the programmers will all desert you, and you'll have a nice place to argue, but no more software. Core here does an excellent job, with all the problems they face, most committers will agree to that pretty quickly, and they are the only ones with a vote. Look to reality for the reasons why. No need for blowing up, so relax. You may wanna grab that bourbon bottle yourself and take a sip. Maybe you're right, but I'm tired to people talking about core like they're some evil overlord group. These guys are longtime FreeBSDers. They've been doing it a long time, and a large part of why they are still doing it is because of a feeling of responsibility. They're doing a great job, even if it's not 100% without error, and FreeBSD would go right down the tubes pretty quickly without coolheaded guidance, just because of the lack of control. You don't have to look hard at all to see several recent (and some ongoing) episodes of folks trying to go off on their own, and the only real restraint is the realization of what kind of limits core will allow. It's got a *great* track record. We can argue specific issues, but attacking core itself, that I'm going to jump up and shout about. 2) Nothing was ever said about telling volunteers what to do or not do. You referred to a group other than core setting policy. No, I did not say setting policy. A place for an appeal or an oversight. I'd never advocate a group other than core for policy - if that's what you got out of it then either you misread or I poorly worded something. If it's the latter then I apologize. 3) Nothing was mentioned about the technical abilities of an appeals board or oversight group. You said that group would have no committers or core on it. Anyone who's shown skill and time has been pretty quickly asked to become a committer, so that pretty much means you're asking for either non-technical folks, or folks without the time to follow things close enough to have any real idea what's going on. Seeing as you did admit you haven't followed the issues closely enough yourself, you're one of the ones you figure would be on that board, right? Actually no. I haven't followed the issues closely enough by choice. I'm not sure I'd really want to get that deeply into the politics of it. Even if asked I can't say that I'd consider doing it. The reason I'd want no core or committers on it is strictly for political reasons. Core *appears* to hold a heavy hand and it's very possible the committers and/or coders are intimidated by them. Now with that scenario would you want either to be on any such committee? I'm trying to look at this from a completely detached viewpoint. 4) Ever do or say something that someone told you that you're out of line? Oh, yeah, sure, I make mistakes. Maybe wrong here, but I said above what keyed me off. It sure isn't bragging if I say here that I'm willing to bet I make more mistakes than you do, but I don't think I'm wrong here. I dunno, I could probably give you a good run :) 5) Let's go back to your volunteer thing. You have volunteers willing to work for you - for free. It's no secret that in the past core has been a problem for some (or maybe even many) of these volunteers. They went away. As has been pointed out endless times, you have to know how to code and be willing to read FreeBSD code enough so that you can contribute well integrated code. If you can't code or don't have the time, no, you can't contribute that way. You can help us by putting in problem reports, but not by trying to gain control, even a small part. The coders control FreeBSD, because they love it. Those are really the only folks who get to directly contribute. Free contributors, out of control, are a mob. Can't the same be said of a closed minded group whether they're core or contributers? If there's noone they can go to, why should they (or anyone else) bother to volunteer? The FreeBSD mailing lists are the most active, quick response groups on the net. Don't you feel silly claiming there's no one they can go to? Not at all. Why should this ever have gotten to the lists? Don't you feel silly that it had to be aired in public? Matt's complaints were expressed just a few months ago in this same forum. silly is a weak term to describe why it was handled the way it was, doncha think? Embarassing for *all* of us (core, user, contributer, bystander, floorsweeper, whoever) is more like it. Earlier in this thread Matt was accused of running rough shod over everyone. Looking over the history and hearing the complaints of some of those involved, I admit not knowing both sides of the FULL story, that core may be partially to blame. But who is there for the *VOLUNTEERS* to turn to? Core? They
