From owner-freebsd-stable@FreeBSD.ORG Tue Sep 23 20:37:07 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97DA61065685; Tue, 23 Sep 2008 20:37:07 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6D48FC12; Tue, 23 Sep 2008 20:37:07 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [172.16.12.8] (covad-jrhett.meer.net [209.157.140.144]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8NKb3Gw065931; Tue, 23 Sep 2008 13:37:04 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.957] Message-Id: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> From: Jo Rhett To: cperciva@FreeBSD.org, Robert Watson , "Simon L. Nielsen" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 23 Sep 2008 13:37:03 -0700 X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable Stable Subject: proposed change to support policy for FreeBSD Releases X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 20:37:07 -0000 Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems "better". Old text: > Each branch is supported by the Security Officer for a limited time > only, and is designated as one of `Early adopter', `Normal', or > `Extended'. The designation is used as a guideline for determining > the lifetime of the branch as follows. > > Early adopter > Releases which are published from the -CURRENT branch will be > supported by the Security Officer for a minimum of 6 months after > the release. > Normal > Releases which are published from a -STABLE branch will be > supported by the Security Officer for a minimum of 12 months after > the release. > Extended > Selected releases will be supported by the Security Officer for > a minimum of 24 months after the release. Proposed (starting point for discussion for) new text: Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or 'Final'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. A release which is not the final minor release of a branch will be additionally supported by a minimum of 6 months past the release date of the succeeding version. For example X.1 will be supported for 12 months or until 6 months past the release date of X.2, whichever comes later. Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. OBSERVATIONS: 1. This avoids the need for the well-documented chicken-and-egg problem of trying to guess which release is the final release. 2. This is a consistent policy in line with many other vendor policies. 3. This rewards forward movement in the branch. And finally, as I've done the match carefully, 4. It would appear to *reduce* rather than enlarge the support requirements for the security team. Unless a minor release comes out less than 6 months after a previous release, only two versions would ever be supported at the same time. In recent history 3 minor releases in the same branch have been supported more often than not. Example under current policy: 6.5 comes out in July of 2009. For July -> October the security team will need to support 3 releases: 6.3, 6.4 and 6.5. From November 2009 through January 2010 the security team will need to support 6.3 and 6.5, but not 6.4. Revised under the existing policy: Support for 6.3 expires in April of 2009. (more than 12 months past release and 6 months after the release of 6.4). Support for 6.4 expires in January of 2010. Support for 6.5 would expire in July of 2011 or 6 months after the release of 6.6. ^NOTE: this example is probably unfeasible since 6.3 already has a published support period ended in January 2010, but this will prevent a similar occurrence happening in future releases. Note2: This new policy would not change the support period for 6.4 if it is the final release, but it does completely resolve the need to "guess" whether or not it will be the final release. The notable change that I believe will encourage business participation in the testing/evaluation process is that 6.4 is guaranteed to be supported either 24 months, or at least 6 months past the release date of 6.5. (recent history suggests this would be 15-19 months). This encourages businesses to test and evaluate 6.4 NOW, rather than waiting until a decision about the support policy is made. Repeat from the top: nobody is demanding anything. I think this policy would make a lot more sense, and would promote forward movement. Feel free to correct me if we overlooked anything. Thanks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness