Date: Thu, 5 Oct 2000 22:53:55 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Jordan Hubbard <jkh@winston.osd.bsdi.com> Cc: John Baldwin <jhb@FreeBSD.org>, Brett Glass <brett@lariat.org>, freebsd-security@FreeBSD.org, cvs-committers@FreeBSD.org, Paul Richards <paul@originative.co.uk>, "David O'Brien" <obrien@FreeBSD.org>, Ralph Huntington <rjh@mohawk.net> Subject: Re: Stable branch Message-ID: <Pine.NEB.3.96L.1001005224010.57431A-100000@fledge.watson.org> In-Reply-To: <1275.970785509@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Oct 2000, Jordan Hubbard wrote:
> > 2) Make release tags into branches, so that ERRATA and other relevant
>
> That scares me. I don't like the idea of n-way merges.
I'm not sure I see the n-way merge.
When it's release time, you add -b to your release tag.
When a fix is required, you merge it into -STABLE, and then if
appropriate, into the release branch also. Most of the time, the release
branch will only be touched for release-specific ERRATA, version number
references, etc, and then occasionally for specifically back-ported
security bugfixes or fixes related to release engineering botches. This
means that after the release freeze ends, it's still possible to tweak the
release in the CVS tree. I would anticipate few if any changes ever being
made to a release branch, but it would provide people a way to synchronize
with release patch levels using cvsup and so on, rather than having to
manually apply patches, and the SO having to verify manually that patches
apply to release versions as well as to -STABLE.
This seems to reflect our various forms of customers:
1) I have a release, it has been tested extensively for production
deployment, and I don't want to track -STABLE. I do want to be able to
manage vital bug fixes and security fixes in this context. Upgrades and
feature deployments are major events, meaning I need a stable code base
that has been through a formal QA process.
Answer: Track a specific RELEASE branch. Updates to the branch will be
well tested, infrequent, and typically announced in the form of a
security advisory or patch level announcement.
2) I have a release, and want to gradually pick up well-tested feature
improvements over time, and avoid major jumps associated with version
upgrades. I can tolerate a moving code base to gain these features, and
when a security fix or vital bug fix comes out, I can afford a deployment
process.
Answer: Track a recent STABLE branch. Updates to the branch will be
well tested, relatively frequent.
3) I'm an active developer or user willing to live on the edge in order to
have access to, or assist in developing, new features in the FreeBSD
operating system. Code changes don't scare me, I have ankles of steel
that cannot be broken by errant committers.
Answer: Track a recent CURRENT branch. Updates to the branch will
be exciting, and quite frequent.
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
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?Pine.NEB.3.96L.1001005224010.57431A-100000>