Date: Tue, 25 Apr 2000 10:18:44 +0100 From: Paul Richards <paul@originative.co.uk> To: Bill Fumerola <billf@chc-chimes.com> Cc: Richard Wackerbarth <rkw@dataplex.net>, Matthew Dillon <dillon@apollo.backplane.com>, freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility Message-ID: <390562F4.550B65EE@originative.co.uk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?390562F4.550B65EE>