From owner-freebsd-stable Tue Jun 18 9: 1:52 2002 Delivered-To: freebsd-stable@freebsd.org Received: from popmail.ct.lodgenet.com (mozart.lodgenet.com [204.124.122.253]) by hub.freebsd.org (Postfix) with SMTP id E52A037B41B for ; Tue, 18 Jun 2002 09:00:56 -0700 (PDT) Received: (qmail 20019 invoked from network); 18 Jun 2002 16:06:25 -0000 Received: from windoze.ct.lodgenet.com (HELO windoze.lodgenet.com) (10.0.122.50) by popmail.ct.lodgenet.com with SMTP; 18 Jun 2002 16:06:25 -0000 Message-Id: <5.1.0.14.2.20020618104548.02249c00@popmail.ct.lodgenet.com> X-Sender: johnp@popmail.ct.lodgenet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 11:00:53 -0500 To: Fred Clift From: John Prince Subject: Re: ATA Atapi 4.6 Release Cc: John Prince , In-Reply-To: <20020618092610.M32141-100000@vespa.dmz.orem.verio.net> References: <5.1.0.14.2.20020617112839.030a9ff8@popmail.ct.lodgenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello Fred. Thank you for your comment. I partially agree with you. >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. 4.6-release should be of a stable nature, when released, should it not? While I agree not all bugs can be removed, this one hurts.. There is a temporary solution that will, minimally band-aid the problem until an actual fix is committed. Innovation, or "New Features" should not compromise the functionality of existing and "standard" hardware. Yes I may be a corporate user, I am also a developer, and have been using/supporting FreeBSD for 8+ years. Stereo-typing the "end User" is not the problem, nor is it a solution. --john At 09:38 AM 6/18/2002 -0600, Fred Clift 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. > >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 > > > >-- >Fred Clift - fclift@verio.net -- Remember: If brute >force doesn't work, you're just not using enough. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message