On Tue, 25 Apr 2000, Paul Richards wrote:

> branch. Most commercial users are not developers, and have no interest
> in anything relating to development. Professional sysadmins are
> conservative creatures, they expect professional quality code to play by
> the rules of the industry and those rules are widely accepted as meaning
> that stable branches do no undergo ABI changes. Such changes are
> reserved for major upgrades because of the consequences and risks
> involved.

On a similar note: I think one of serious drawbacks of FreeBSD's model for
updating and bugfixing the stable branch is 'make world'. It's very
inefficient and cumbersome way to do this on production machines. STABLE
is stable enough for us to be able to prepare binary patches, which can be
applied to a system in some (known) version. Especially security fixes,
which are usually limited to specific programs.

With such system present I'd be completely satisfied (as a production
manager, not as a developer) if I could start with, let's say,
3.4-RELEASE, and then apply binary patches one by one to track
STABLE. Instead of putting the machine out-of-service for a couple of
hours, it would be 10 minutes. Also, no need to keep the sources
around. Of course, implementing such a system requires careful versioning
of each file in the standard system, but I think it's possible - just
having the MD5 checksums around, for each consecutive patch, should do for

Don't get me wrong - I love to see what's under the hood, analyze the
sources etc. But it's not what is expected in a production environment,
(IMHO of course :).

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// -------------------------------------------------------------------
// ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to