From owner-freebsd-security Thu Oct 5 19:54: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2889C37B502; Thu, 5 Oct 2000 19:54:01 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id WAA57645; Thu, 5 Oct 2000 22:53:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 5 Oct 2000 22:53:55 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jordan Hubbard Cc: John Baldwin , Brett Glass , freebsd-security@FreeBSD.org, cvs-committers@FreeBSD.org, Paul Richards , "David O'Brien" , Ralph Huntington Subject: Re: Stable branch In-Reply-To: <1275.970785509@winston.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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