From owner-freebsd-security Sat Oct 7 20: 1:13 2000 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id AA8AB37B66C; Sat, 7 Oct 2000 20:01:08 -0700 (PDT) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id WAA20262; Sat, 7 Oct 2000 22:01:07 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-73.max1.wa.cyberlynk.net(207.227.118.73) by peak.mountin.net via smap (V1.3) id sma020256; Sat Oct 7 22:00:40 2000 Message-Id: <4.3.2.20001007214506.00bb7c10@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 07 Oct 2000 21:59:48 -0500 To: Robert Watson From: "Jeffrey J. Mountin" Subject: Re: Stable branch Cc: "Matthew D. Fuller" , Jordan Hubbard , John Baldwin , freebsd-security@FreeBSD.ORG, cvs-committers@FreeBSD.ORG In-Reply-To: References: <4.3.2.20001007161924.00b72460@207.227.119.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:51 PM 10/7/00 -0400, Robert Watson wrote: >You seem to misunderstand. No one is asking the majority of committers to >commit to the release branches--in fact, that was specifically >*prohibited* in the recommendation of a branch for each release. These >branches would only exist for the purposes of release-related activity >(modify the version numbers in the release branch, not the -STABLE >branch), emergency back-ports during and immediately after the release >itself, ERRATA entries for the release,and for security bugfixes. No new >features. No new documentation work. Show stopper fixes only. Now your earlier proposal makes better sense. At lot more for the CVS-meisters to deal with, but they can answer that magic question. Also may be an issue to branch old releases, then it might be worth doing all the branching at one time and disallowing access. Then the question would be for how long do we want to do patches for old releases. One other idea that cropped up would be if we want to set this up for the more troublesome releases like 3.2 to force them to upgrade to a later version. Think that only 3.4+ should be considered due to a large enough install base to consider. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message