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>