Date: Thu, 20 Jun 2002 22:43:41 -0700 From: "Lucky Green" <shamrock@cypherpunks.to> To: <freebsd-stable@freebsd.org> Subject: Re: ATA Atapi 4.6 Release Message-ID: <003301c218e6$9f7d7820$206694d1@LUCKYVAIO>
next in thread | raw e-mail | index | archive | help
Fred wrote: ----------- On Mon, 17 Jun 2002, John Prince wrote: > > If not, can someone reply as to why the stability of FreeBSD was > compromised in favor of an improved method, that does not quite have > the bugs out of it.. Well, in response to this, I can give you my conjecture. There are differing viewpoints on what FreeBSD is all about. There are many different ways to classify FreeBSD users, but for the moment think of them as 'corporate users' and as 'os developers'. >From the corporate side, people tend to want predictable release dates, >a very codified, process driven system for handling bugs, 'full' stability, backward compatibility etc. For the developer side, FreeBSD is about doing cool things with the operating system of your computer. Making things work better/nicer, or just experimenting etc. I would say that over time, the corporate-type people have become more influential in the project and the world has changed in such a way as to make 'change' harder. It appears that your bias is towards stability at the expense of innovation (I realize that they need not be not mutually exclusive). Other's bias is toward getting new features at the expense of some compatibility. ------------- Fred raises an interesting and important question: what are the expectations FreeBSD users have of the operating system? Or more precisely, what are the benefits that FreeBSD offers amongst the great many operating systems in existence that cause those who choose FreeBSD to make that choice? And have these reasons changed over time? Now some may say users choose FreeBSD because it is the best OS in the world. I suspect we all know that such a view would probably be a bit too simplistic. So what are FreeBSD's main benefits over other operating systems? Is it support for the latest and greatest video hardware and games? No, that one probably goes to Windows. Is it because FreeBSD offers the nicest UI? Nothing based on regular X stands much of a chance of ever claiming that title. I'd have to give this one to OS X. Is it because FreeBSD is a hip and inexpensive alternative to Windows or OS X for a desktop that will make your friends think that you are cool? Nope, this one likely goes to Linux. Is it because FreeBSD will run on your old SPARC hardware better than SunOS ever did? Negative, that would be NetBSD. So, what does FreeBSD have that would make a user choose FreeBSD? I know why I chose FreeBSD, why others that I know are using FreeBSD, and why some people I know that are currently using Linux are migrating to FreeBSD. The answer I heard was always the same, today as it was years ago: FreeBSD is an extremely stable, well performing, well tested, server OS that runs reliably on comparatively inexpensive hardware. I believe that this is the key differentiator, perhaps the only differentiator, that keeps FreeBSD in the game as a viable OS rather than being squeezed out of the market by Linux on one side and OpenBSD on the other. Does this mean that innovation can or should not take place? Of course not. But I believe it to be critical that the innovations taking place, in particular those that make it into production releases, meet the above criteria. The ATA bugs were a rather unusual case: the developer had a hard time reproducing and tracking them down, the release clock was ticking, and the fixes just couldn't be produced in time for the release. This is nobody's fault, as an isolated incident, this is simply bad luck. With the release already behind schedule and given the alternative, releasing with the bugs was, while undoubtedly an unpleasant choice to the RE team, IMHO the best choice that could be made under the circumstance. But this was an exception that if at all humanly feasible should be attempted to be avoided in the future. If given the choice of FreeBSD making a habit of releasing with known bugs that cause regression to fail and releasing without the feature, I believe in all but the rarest of cases FreeBSD should release without the feature. Or not release at all. (More on that later). Any other approach is bound to sooner or later remove the justification for using FreeBSD's in the minds of many current and even more future FreeBSD users. ----------------- [...] One could argue that it might have been better to mfc earlier (ie right after 4.5-R) or wait till after 4.6-R so that the most time possible for working out these kinks could be used. I dont know what factors accompanied the timing of the MFC but I think that if we were going to do it at all, we just had to pick a time and do it. Never could all the bugs be worked out between any two releases, even with the most optimal timing, so if we want the new code at all, we just have to bite the bullet and work with it. ----------------- I believe the sole justification for releasing with the ATA bugs was because the bugs were of the kind for which a fix was potentially a few days off for a great many few days. This can happen and it is extremely frustrating for project management, engineering, and the users when it does. If it is indeed the case, as you submit, that it was clear or even only likely from the beginning that a feature cannot be made stable in one release cycle, in general the following options exist: 1) break the feature into pieces that can be tested and made stable independently. Depending on the feature, this may or may not be technically feasible. 2) lengthen the release cycles. If it is known in advance that a feature cannot be broken into small enough pieces to be made stable in any release cycle and you do intend to include the feature at all, your release schedule is too ambitious given your available resources. If so, it would be downright irresponsible to not reduce the number of annual releases. 3) release with the bug. This option can only be justified if project management did not know that the schedule could not be met, had good reason to believe that a fix would be found in time to make the release date even after the schedule started slipping, the cost of backing out the changes are exceptionally high, the number of users affected is minimal, and the broken regression is extremely visibly documented. If this option were to be chosen more than on the rarest of occasions, something is wrong with the process. (I believe the ATA bugs fell into this rare category). Having said all this, I am very much looking forward to some of the new features in 5.0, in particular GEOM and the (hopefully stable ;) transparent drive encryption it provides, which has been the one glaring hole in my security requirements for years. YMMV, --Lucky, just another user. 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?003301c218e6$9f7d7820$206694d1>