Date: Thu, 3 Jun 1999 20:07:23 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: nate@mt.sri.com (Nate Williams) Cc: dillon@apollo.backplane.com (Matthew Dillon), freebsd-hackers@FreeBSD.ORG Subject: Re: Matt's Commit status (was Re: 3.2-stable, panic #12) Message-ID: <199906040107.UAA24486@dyson.iquest.net.> In-Reply-To: <199906032021.OAA23554@mt.sri.com> from Nate Williams at "Jun 3, 1999 02:21:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 boxes.) In order to start from where the code is today, instead of starting from scratch or loosing capabilities, fully understanding the code is necessary. When Matt first started, it was pretty clear that his understanding was superficial, and enough to make non-strategic changes to the code. In order to understand the code in depth it probably takes at least several mos for a competent programmer. It is likely that there are still pieces that he doesn't understand, but also it is likely that he now knows more about the areas that he doesn't fully understand, and recognizes that there are *sometimes* things under the surface that require careful study. My guess is that he probably didn't initially recognize that fact, and that is one reason why he didn't feel like he needed the answers to the questions that he didn't know that he needed to ask :-). Note that when the FreeBSD code was initially being upgraded to what it is today (over the last 5yrs), there were few resources for DG and I to utilize. Now, there are such resources (the current developers can use DG or me, or other longer term developers. Matt has ALC working with him also.) When we were moving the codebase aggressively forward, doing some things that weren't done before (especially in source-available code), we didn't have anyone to ask. Now the developers have a much better support system, and there are fewer excuses for regression in the codebase. Some of the reasons for FreeBSD's behavior are not individual features in isolation, but are a result of the interaction of various design choices. It is difficult to express those kinds of facts when the reasons for the individual choices aren't well known by the person trying to interpret the information and design choices. There was a strong need for bidirectional communications, and a need to *convince* Matt that there are more things going on under the hood than most people would initially observe. There are some pieces of the code that are designed a certain way, with the plan for the future to eventually formalize the implementation. A good example of this was the way that the pageout queues were managed. It is very easy to overlook the reason for the code to do what it does :-). An open discussion amongst developers would have clarified the reasons for the design choices, and the 1Hr/wk or so on the phone would have been alot more efficient for my time than spending alot of time (>>1Hr/wk) writing docs that I unfortunately didn't have the time to produce. (One of the reasons why I had to quit FreeBSD was extreme burnout due to the creation of a vast amount of backlogged work... I just couldn't do "it" anymore until I recovered. I had lots of stuff cooking for FreeBSD at the time.) The pageout queue blowup wouldn't have happened if a phone call was made, and I could have explained why it was needed. (That would have taken a few minutes, and there would have been no public discussion.) By asking questions, people often get more of an answer than they really need. When dealing with complex issues, it is best to talk on the phone, and I continue to suggest that on an as needed basis. Some simple phone calls can eliminate alot of friction. Perhaps I should have provided more time to him, but I really couldn't then, and I sometimes could only provide help in the form of "hints". If those hints were listened to, most of the problems and regressions that have transpired wouldn't have happened. Sometimes I have been wrong in technical areas where I might be expert, but few people can truthfully claim that I don't admit it when I am wrong, and try to correct the effects of my misunderstanding. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. 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?199906040107.UAA24486>