Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Oct 2000 21:27:12 -0500
From:      "Matthew D. Fuller" <fullermd@futuresouth.com>
To:        Bill Fumerola <billf@chimesnet.com>
Cc:        "Jeffrey J. Mountin" <jeff-ml@mountin.net>, Jordan Hubbard <jkh@winston.osd.bsdi.com>, Robert Watson <rwatson@FreeBSD.ORG>, John Baldwin <jhb@FreeBSD.ORG>, freebsd-security@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Subject:   Re: Stable branch
Message-ID:  <20001007212711.A24996@futuresouth.com>
In-Reply-To: <20001007194730.T38472@jade.chc-chimes.com>; from billf@chimesnet.com on Sat, Oct 07, 2000 at 07:47:30PM -0400
References:  <3175.970802405@winston.osd.bsdi.com> <rwatson@FreeBSD.org> <3175.970802405@winston.osd.bsdi.com> <20001006180148.B29088@futuresouth.com> <4.3.2.20001007161924.00b72460@207.227.119.2> <20001007194730.T38472@jade.chc-chimes.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 07, 2000 at 07:47:30PM -0400, a little birdie told me
that Bill Fumerola remarked
> 
> Speaking as a {lazy,busy} committer: Mergeing to one branch is a pain,
> mergeing to multiple branches is even worse. Merging to RELENG_4_1,
> RELENG_4_2 etc means I would have to have a machine with the latest
> -STABLE of those branches, which is something I doubt I'll have every
> permutation of...
> 
> BUT
> 
> If all we did was merge critical security "oh-my-god" type fixes into those
> branches I'd be all for it (I'm not taking into account the CVS hell this
> would make in our RCS files, however..).

(reply to all the messages, public and private about this in one place)
That was my intention there; god knows I wouldn't want to deal with
having 8 -STABLE branches at once!  But a per-release branch for the
'oh shit' security holes, and possibly showstopper bugs, might be doable.
I understand the branching does fun things to CVS, so it's a tradeoff
either way; CVS twiddleadge and rare (hopefully VERY rare; we don't make
mistakes, do we? ;) commiter time, vs. easier updates to specific
releases.

And if we bump patchlevels on the release (3.5.1-RELEASE p2 or something
similar in uname), we can make it easier on the users to see when they
have a patched version.

Possible fun problems I see include rolling releases, having them on FTP
sites, etc.  OTOH, keeping only the latest patchlevel on the FTP sites (I
doubt there'd often be more than 1 or possibly two patches per release,
big security holes in the base system aren't THAT common) would make it
easier to keep new installs having secure systems, and just keeping the
per-release branches updated for X time (1 year?  2 years?) would keep it
from snowballing out of control as we go through 5-STABLE, 6-STABLE, etc.


-- 
Matthew Fuller     (MF4839)     |    fullermd@over-yonder.net
Unix Systems Administrator      |    fullermd@futuresouth.com
Specializing in FreeBSD         |    http://www.over-yonder.net/

"The only reason I'm burning my candle at both ends, is because I
      haven't figured out how to light the middle yet"


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




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