Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Apr 2022 06:11:00 +0100
From:      Steve O'Hara-Smith <steve@sohara.org>
To:        iio7@tutanota.com
Cc:        Freebsd Questions <freebsd-questions@freebsd.org>
Subject:   Re: Why do we have to wait for the next release for bug fixes?
Message-ID:  <20220412061100.cd71c9815f90ad3c9f7802d0@sohara.org>
In-Reply-To: <N-R0gZ---3-2@tutanota.com>
References:  <N-R0gZ---3-2@tutanota.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Apr 2022 06:27:28 +0200 (CEST)
iio7@tutanota.com wrote:

> Why are all bug fixes not errata'd so that users can update their systems
> with freebsd-update without having to manually patch the kernel or
> wait until next release of RELEASE, which can be quite a long wait.

	Every code change brings risk, releases are expected to be stable
and reliable. These two facts drive the very common policy of being careful
about what changes are permitted on release branches - security and
important (sometimes that's a sliding scale depending on age of release)
bug fixes are the usual policy for production quality software everywhere
I've worked. Minor bugs with minimal impact, bugs with easy workarounds,
risky intrusive code fixes these all wait for the next release as a simple
matter of risk management.

	With FreeBSD development and bug fixing occurs in -current at the
head of the tree, things that are suitable for backporting to the stable
branch and thus going into the next release are marked to be merged after a
soaking period in -current - these are mostly bug fixes and minor feature
enhancements, large changes remain in -current where they can't destabilise
the stable branch. A small set of the changes to the stable branch meet the
criteria for patching the release, these criteria are chosen to maintain
the reliability and security of the release branch and avoid surprises for
sysadmins.

	The result is a set of choices depending on your needs.

	Production systems with strong reliability requirements should use
releases and freebsd-update. This is because releases receive extensive
testing and stabilisation (betas, RCs ...) to eliminate as many bugs as
possible. Patches to release branches in freebsd-update also receive
careful testing to maintain this quality - fortunately they are focused and
do not require the entire panoply of release testing but even so the work
involved is substantial.

	For early access to next release fixes and features you can compile
the stable branch - this is a constantly moving target in the source
repository, changes are limited, testing is minimal, slippery when wet
YMMMV.

	For early access to the next main branch you can compile -current -
changes are unlimited, all the rest applies even more so.

-- 
Steve O'Hara-Smith <steve@sohara.org>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220412061100.cd71c9815f90ad3c9f7802d0>