Date: Tue, 18 Jun 2002 14:57:04 -0700 From: "Philip J. Koenig" <pjklist@ekahuna.com> To: stable@FreeBSD.ORG Cc: Fred Clift <fclift@verio.net>, John Prince <johnp@lodgenet.com> Subject: Re: ATA Atapi 4.6 Release Message-ID: <20020618215704779.AAA649@empty1.ekahuna.com@pc02.ekahuna.com>
next in thread | raw e-mail | index | archive | help
> Date: Tue, 18 Jun 2002 09:38:46 -0600 (MDT) > From: Fred Clift <fclift@verio.net> > 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. In this particular case, the ata-drivers are a > two-edged sword. People want them so they can hot-plug ata devices > (especially raid devices), which the new framework/driver allows. 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. Fred One thing that you are missing here is that the majority of people that are running STABLE code are not installing brand-new systems from CD ISO images. For a substantial proportion of people that run FreeBSD, the new stuff comes in the form of full releases on CDROM. (which accounts to a great extent for why so many people were asking "where's 4.6" recently after the release date slipped a couple of times.) It seems to me that the majority of people who recently encountered at least the CDROM problems were doing first-time installs from CD. This is not the kind of testing that the people running STABLE are doing much of, because most of them are incrementally upgrading the source and rebuilding without touching the CD. Therefore it's not really surprising that these issues weren't foreseen more than they were. (even though I admit that there had been complaints about the CD problems prior to when 4.6 shipped - it wasn't so apparent until all those people started doing those new installs) -- Philip J. Koenig pjklist@ekahuna.com Electric Kahuna Systems -- Computers & Communications for the New Millenium 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?20020618215704779.AAA649>