Date: Mon, 11 Jun 2001 20:03:32 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Mixtim <mixtim@home.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Why is the STABLE branch not so stable anymore? Message-ID: <p05100e20b74afe263e07@[128.113.24.47]> In-Reply-To: <20010611172443.A18552@home.com> References: <20010611172443.A18552@home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:24 PM -0400 6/11/01, Mixtim wrote: >Several times in the last few weeks people have broken >the STABLE branch, sometimes for days at a time. Why has >this started happening? Is there no process to prevent >this from happening? You say "started happening", as if it has never happened before. Unfortunately, there are times when stable does not build. No one intends this, and many committers work very hard trying to avoid it. They are no happier about it than you are, as they are probably building stable (or trying to...) more often than the average user. Still, we have not reached the state of perfection yet, and unfortunately things break from time-to-time. Things go good for awhile, and then we have a run of several changes which happen to break stable. That does not mean anyone has stopped trying, it just means that "shit happens". As a human being on God's green earth, you are inevitably faced with a lot of areas where "shit happens". Why would you not expect the occasional slip-up on an operating system which is provided to you for basically nothing? >I have a wild idea. How about making everyone who commits >to the STABLE branch actually: > > 1. Checkout a clean copy. > 2. make buildworld. > 3. Actually test the programs they changed. And guess what. That won't find all the problems. That is a fact of life. Sometimes you change a program, and the program you CHANGE works fine, it's some OTHER program which you did NOT change which stops working. I think one of the recent breakages was due to someone making a change to freebsd-current, not realizing it would have ANY affect AT ALL on freebsd-stable. So, basically, you have to remember to test all the programs you are not changing, in addition to the ones you are changing. I believe this goes by the name of "regression testing". Yes, it would be very nice to do. No, it is not easy to do. It is very time-consuming to do a good job at it. It requires a lot more work than someone sitting down and writing a sarcastic 3-point list. I'm sure I could trivialize your life into a three-point list if I had the desire to. >These three steps would have prevented each of the problems >in the last few weeks. Does no one test anymore? Is no one >required to test? Your first sentence is not true. As to your two questions, committers are expected to test, but that doesn't mean they manage to test all possible permutations. This project simply does not have the resources (in people and machines) to do that. If this bothers you, I'm afraid you'll have to go searching to some other operating system. Let me know when you find the perfect OS, because I certainly would rather work on a perfect OS than any of the six-to-ten OS's that I currently work on. To give you an idea of how much work can go into a change, I recently made a two-line change to /bin/sh. Two lines of actual code, plus maybe another eight lines of comments. I, personally, spent more than twelve hours testing those two lines of code. I also asked for input for others. And when I finally committed it, the only complaint I got from any other developers was that I had not tested it ENOUGH. In some respects that was true, but there was also tiny issue that I can not afford to spend more than six hours per line of code that I contribute to freebsd. [mind you, it is still true that no one has found any actual problem with those two lines of code. It's just that they would have felt more comfortable if there had been additional testing on it -- and that was for a change going into -current] Most developers take quality control as seriously as they can afford to, given their own time constraints. They take a lot of pride in the work they do, and they do want to be known for doing the best job possible, and for developing the best operating system available. >Perhaps a process should be put into place. (unless there >already is one in which case someone should start cracking >the whip over some backs). It is funny how often it is the non-contributors who are eager to start "cracking some whips" on the backs of people who are providing you a system for free. When I worked those twelve hours testing two lines of code, you did not pay ME a single dime. You have not paid a single cent towards the hardware that I use for developing freebsd on. Perhaps you paid $30 for the CD that someone pressed for you. None of that money goes to me. In fact, I also pay for my own freebsd CD's, even though I don't need the CD's for the work I do. What "whip" do you fantasize that you're going to crack on my back? You think I'm supposed to work "even harder" for you? Based on what? Because "you'd like it"? If you want a more-perfect system, then you should sit at releng_4_3 instead of releng_4. You do not seem to be in the right mindset for running stable, in which case the problem is that you are running the wrong branch of freebsd. Do not be surprised if very few developers look kindly on your comments. The reason developers (including me) will react so strongly is precisely that they DO care, and they DO work hard to avoid any breakage to -stable. Please be assured that no one is cavalier about any of the recent breakages. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05100e20b74afe263e07>