From owner-freebsd-stable Tue Jun 18 10:41:21 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 82D8337B408 for ; Tue, 18 Jun 2002 10:41:08 -0700 (PDT) Received: (qmail 24216 invoked from network); 18 Jun 2002 17:46:38 -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 17:46:38 -0000 Message-Id: <5.1.0.14.2.20020618122956.02267258@popmail.ct.lodgenet.com> X-Sender: johnp@popmail.ct.lodgenet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 12:41:05 -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: multipart/alternative; boundary="=====================_1035723812==_.ALT" 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 --=====================_1035723812==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello Fred.. I also want to mention, in our Handbook, last paragraph of section 1.3.3. "In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of FreeBSD, who are thereby provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent application programs that the users can easily install and use, and this model works very well in accomplishing that. " --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 --=====================_1035723812==_.ALT Content-Type: text/html; charset="us-ascii" Hello Fred..

I also want to mention, in our Handbook, last paragraph of section 1.3.3.
"In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of FreeBSD, who are thereby provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent application programs that the users can easily install and use, and this model works very well in accomplishing that.
"

--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
--=====================_1035723812==_.ALT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message