From owner-freebsd-current Tue Apr 25 2:18:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 0E7EB37B6F8 for ; Tue, 25 Apr 2000 02:18:48 -0700 (PDT) (envelope-from paul@originative.co.uk) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id E19541D161; Tue, 25 Apr 2000 10:18:44 +0100 (BST) Message-ID: <390562F4.550B65EE@originative.co.uk> Date: Tue, 25 Apr 2000 10:18:44 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en-GB, en MIME-Version: 1.0 To: Bill Fumerola Cc: Richard Wackerbarth , Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <200004231909.MAA09128@gndrsh.dnsmgr.net> <00042315420301.24082@nomad.dataplex.net> <200004240605.XAA66216@apollo.backplane.com> <00042404464300.09955@nomad.dataplex.net> <20000424144441.W397@jade.chc-chimes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bill Fumerola wrote: > > On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote: > > > >From the USER's perspective, anything that requires me to as much as reload > > a module/program that I have already installed "breaks" it. > > The fact that it is only necessary to recompile it in order to fix it only > > means that it is easy to fix IF I have the source code. > > No-one forces you to upgrade you systems. Partial upgrades are something that are > nice when they work, but understood when they don't. > > We don't accept bug reports (typically) when a person hasn't upgraded their world, > kernel, and modules. I don't understand why we're accepting preemptive bitching. The trouble is, if you're running a production system then there will be cases where you really must carry out an upgrade, because of a critical bug fix, even though as the admin you really don't want to touch a live system. When you're running a "stable" code base you expect to be able to patch in these bug fixes if they're required with relatively little pain. However, if rebuilding your kernel to incorporate a critical bug fix 3 months down the line means that you're proprietary drivers no longer work then you're stuck between a rock and a hard place. Stable should mean stable and stability means not changing things unless they're critical bug fixes. Development on the stable branches has become far too fast and loose. It *is* affecting the perception of FreeBSD by commercial users who really aren't interested in getting new features on stable branch, in the main if you want new features you wait for the next major release and you go through all the hassles of regression testing your application on the new version. That's not something done lightly or often and breaking the stable branch and preventing the incorporation of genuine fixes, rather than enhancements, is not helping the adoption of FreeBSD by serious commercial users. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message