Date: Mon, 29 Nov 1999 07:33:37 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Colin <cwass99@home.com> Cc: "Forrest W. Christian" <forrestc@iMach.com>, Stable@FreeBSD.ORG Subject: Re: Bug-fixing previous -RELEASE Message-ID: <199911291533.HAA19643@cwsys.cwsent.com> In-Reply-To: Your message of "Sat, 27 Nov 1999 12:35:25 EST." <3840165D.CAF495E9@home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3840165D.CAF495E9@home.com>, Colin writes: > Forrest W. Christian wrote: > > > > Hmm, this brings up another interesting question. First, to put this in > > context: > > > > Jordan K. Hubbard wrote: > > > Actually, the -missioncritical branch is sort of provided for > > > now as a function of -previousstable. There are plenty of people still > > > running 2.2.x, for example, and you even still occasionally see commits > > > to the 2.2.x branch. > > > > Ok, so, let's assume I JUST want to incorporate bugfixes into the -RELEASE > > (be it 3.x or whatever) that I have on a particular machine. How would I > > go about doing this? > > > My intent was actually a little different from the responses that > are elswhere in this list. My thought was, when you find a bug that > affects you, get the diffs/upgraded source that fixes that problem only > and apply. I'm new enough to this branch that I don't know for sure how > difficult that would be, but I don't imagine it would be that big of a > deal. You could also move just far enough up the source tree to fix > your current problems and stop there, but at that point, there's no more > risk than tracking -STABLE completely. This approach does work (usually), however there are times that a fix may require prerequisite patches. Sometimes you end up with a long chain of prerequisites that need to be installed that eventually leads into an abyss. In that case you need to carefully decide whether to sync up with -stable or live with the bug. Usually what I do in the above situation is run the "new" O/S from another disk or slice, then if it breaks something or customers complain and no fix can be found, the backout is a simple reboot. Once the "new" O/S has been running for a couple of weeks or so, you can safely reclaim the space used by the "old" O/S. This is an approach that I and my team have been using on Solaris, Digital UNIX, and FreeBSD for a number of years. It's an approach I learned in my previous life as an MVS Systems Programmer. Of course none of this beats having a testbed, however O/S's that run nicely on testbeds tend to have problems on production machines because users will do things you've never even dreamed of testing. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" 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?199911291533.HAA19643>