Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Dec 2001 15:59:24 -0600
From:      D J Hawkey Jr <hawkeyd@visi.com>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        Michael Lucas <mwlucas@FreeBSD.ORG>, hackers@FreeBSD.ORG
Subject:   Re: Tangent for discussion: FreeBSD performs worse that Linux
Message-ID:  <20011210155924.A1542@sheol.localdomain>
In-Reply-To: <Pine.NEB.3.96L.1011210152926.4035T-100000@fledge.watson.org>; from rwatson@FreeBSD.ORG on Mon, Dec 10, 2001 at 03:34:58PM -0500
References:  <20011210074151.A29219@sheol.localdomain> <Pine.NEB.3.96L.1011210152926.4035T-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 10, at 03:34 PM, Robert Watson wrote:
> 
> 
> On Mon, 10 Dec 2001, D J Hawkey Jr wrote:
> 
> > I can backport to 4.2REL and 4.3REL (I have these releases), but I don't
> > have the resources (read: "free partitions") to accomodate 4.1 or 4.4. 
> 
> For 4.3-RELEASE, there's a RELENG_4_3 branch in CVS that security fixes
> are committed to; you'd probably want to generate patches with respects to
> the head of the RELENG_4_3 branch so as not to have to duplicate the
> security bug fixes, only the non-security ones that don't go into
> RELENG_4_3.  Otherwise, you'd lose out on some of the more desirable bug
> fixes :-).

Good point.

> Note also that as a release gets older, it drops off the "security-officer
> supported" list, due to a gradual increase in the level of work required
> to support the release.
> 
>    [SNIP]
> 
> How fast the window runs out on a release depends on what needs fixing,
> so it's hard to predict when it will happen.

Understood.

>    [SNIP]

So, my question is then, just what is the policy defining non-current-but-
still-supported-releases?

Right now, these is exactly one such release, 4.3, for security fixes.
Will there always be exactly one, such that when 4.5 is released, 4.3
will fall off the planet, and 4.4 takes its place? Or might there be two,
4.3 and 4.4?

This comes 'round to one of my original questions, too: Why, as an example,
isn't the DELACK patches Matt made recently considered "important" enough
to be backported to RELENG_4_3 (which I have more generically referred to
as RELENG_(current - 1) or RELENG_(release - 1))? It has been said that a
fix might be backported to RELENG_(current - 1) that isn't necessarily a
security issue; can't that be expanded to any (or perhaps just "major")
fixes that don't imply a new feature of RELENG_(current)?

Yes, I know this would mean additional work on the part of the hacker and
committer, but is it not better they do it, than the likes of me, an user/
admin that isn't necessarily in a position to stay -STABLE, but knows
enough of C and patch(1) to pro'lly get things right most of the time?

The problem with the latter is that I can't possibly know of what's
getting fixed in -STABLE (or -CURRENT), or the "severity" of the fixes,
without considerably more effort than that of the former. Then, I still
might not get it right, just 'cuz I'm not the expert the hacker/committer
is.

The site Michael and I have discussed will be hugely deficient in terms
of what can be made available to any previous release (compared to what
is applied to -STABLE), but as it sits right now, it would be better than
nought for those that can't stay -STABLE.

> Robert N M Watson             FreeBSD Core Team, TrustedBSD Project

Dave

-- 
  ______________________                         ______________________
  \__________________   \    D. J. HAWKEY JR.   /   __________________/
     \________________/\     hawkeyd@visi.com    /\________________/
                      http://www.visi.com/~hawkeyd/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




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