Date: Tue, 19 Nov 2002 13:51:29 -0500 From: Bob Johnson <bob@eng.ufl.edu> To: Jonathan Chen <jonc@chen.org.nz> Cc: Mike Hoskins <mike@adept.org>, "Sameer R. Manek" <manek@ecst.csuchico.edu>, freebsd-stable@FreeBSD.ORG, re@FreeBSD.ORG Subject: Re: restoring definition of -stable Message-ID: <3DDA8831.D80CBA7F@eng.ufl.edu> References: <LMEMIKHGPPEEMMMMGIENOEHCFAAA.manek@ecst.csuchico.edu> <20021118150756.W33033-100000@fubar.adept.org> <20021118233258.GA80653@grimoire.chen.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Chen wrote: > > On Mon, Nov 18, 2002 at 03:12:25PM -0800, Mike Hoskins wrote: > > On Mon, 18 Nov 2002, Sameer R. Manek wrote: > > [..] > > > The definition of what is -stable has been relaxed in the past 2 years. If > > > you look at the handbook from 2 years ago, you will see this is what they > > > define it as. > > > > Not surprisingly, I find a lot of changes in the past two years. The > > handbook is a living document, it will change. The current definitions > > explain how FreeBSD works now. If you don't like how it works, it's much > > more effective to volunteer and effect change from the inside out than it > > is to point fingers and make empty suggestions. If you are not qualified > > to help, then it is also unlikely you understand all the issues pertaining > > to your request. > [...] > What we don't have is buy-in from -core; and the only way that will > happen is if enough people voice their concern. It's hard to work from > the inside if you're on the outside, and no one's asking you in. > I don't think this requires more from -core than a desire to try to stabilize -stable after 5.0-RELEASE. My understanding is that right now an MFC often requires a lot of patching to account for the divergent code bases, and in some cases new code can't be tested on -current at all. Being able to test things on -current and then move them to -stable with minimal patching would put us back where we were when -stable was considered "stable". Now, I understand that -stable was never 100% "stable", but making it so was at least a target that was aimed for. There is some validity to the view that a production system shouldn't be trying to keep up with all of the bells and whistles that show up in the latest version of -stable, but at the same time, it would be nice to have some confidence that I can do an upgrade without breaking something. I haven't managed to do that for a few months now (maybe I'm just unlucky). For production servers I use the RELENG_4_x (a.k.a. "secure") branch, and I'm quite happy with it. It keeps my servers on line with minimal risk of breaking something. But for personal workstations that aren't quite so critical, it's nice to be able to upgrade them regularly and keep up with the new features without planning to spend a day figuring out what broke. In summary: - It seems likely (to me) that the release of 5.0-R will automatically solve some of the stability problems on -stable if that is a goal of the committers. - It seems reasonable to me to tell people that -stable is stable enough for a typical workstation (where only one person stops working when it stops), but shouldn't be used on production servers that will affect many people if they break. - It seems reasonable to me to tell people that production servers ought to be using the "secure" codebase rather than the "stable" codebase. Leave the bells and whistles to systems that aren't so critical. - There may be room for redefinition of what constitutes a "critical" patch, but it is a very narrow issue compared to "the stability of -stable". Should a patch to the VM system that substantially improves the performance of a heavily loaded server be considered "critical"? I don't know, but if I follow my argument to its conclusion, I find myself saying "yes" (to my surprise). Since I'm claiming that production systems should stick with the "secure" branch, and that is arguably the primary "market" for that branch, I guess I should also claim that their performance should be considered significant when deciding what goes into that branch. If maximum stability is considered essential, however, then the answer is "no". - Bob 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?3DDA8831.D80CBA7F>