Re: stable vs testing
On Sun, Nov 11, 2001 at 10:30:56AM +1100, Craig Sanders wrote:
> On Fri, Nov 09, 2001 at 03:32:29AM +1100, Jason Lim wrote:
> > We run unstable on our production servers. That means we must be very
> > vigilant in making sure no one else has had a problem. We download
> > the updates, and install them a day or two later after other people
> > have tested it and made sure it doesn't totally destroy the box. The
> > reason we run unstable is because quite a few times we've needed new
> > software, and it just wasn't in stable.
> another good idea is to install the same packages that your server
> requires on another machine (e.g. a development box or your
> workstation). then test every upgrade on that box before doing it on
> your production server. if the upgrade works smoothly on the workstation
> then it's probably OK to run on the production server. if not, then wait
> a few days and run a test upgrade again.
> once you've done this a few times, you get a feel for what kinds of
> problems to look out for, what to keep an eye on during & after the
> in my experience, there is far less risk in upgrading regularly & often
> than there is in upgrading only when there is a new stable release. you
> get small incremental changes rather than one enormous change...one
> advantage of this is that if something does go wrong, it's generally
> only one or two problems at a time, which is much easier to deal with
> than dozens or hundreds of simultaneous problems.
> here's a good rule of thumb for deciding whether to run unstable:
> if you are highly skilled and you need the new versions in unstable then
> it's worth the risk to run unstable.
> if not, then stick to stable. most packages in unstable can easily be
> recompiled for stable (depending on which dependancies you also have to
> recompile for stable...if there's too many, then it becomes more work
> and more risk to recompile than it is to just upgrade to unstable)
Yes, I can second that. Excepting only that if you are skilled enough to
recompile unstable source on stable you are probably more than skilled enough
to run vanilla unstable. :-)
We typically upgrade all our development machines first. For the most part,
that catches most of the issues.
Christopher F. Miller, Publisher firstname.lastname@example.org
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
Content/site management, online commerce, internet integration, Debian linux