From owner-freebsd-stable@FreeBSD.ORG Thu Sep 25 16:31:16 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 E5A6D1065689 for ; Thu, 25 Sep 2008 16:31:16 +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 CCDF68FC0A for ; Thu, 25 Sep 2008 16:31:16 +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 m8PGVB1Z063855; Thu, 25 Sep 2008 09:31:11 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=-0.942] Message-Id: From: Jo Rhett To: Tom Evans In-Reply-To: <1222354401.2443.46.camel@localhost> 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: Thu, 25 Sep 2008 09:31:10 -0700 References: <40C58F46-D705-4BE0-8AE5-17D901EE381A@netconsonance.com> <1222354401.2443.46.camel@localhost> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable Stable Subject: Re: 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: Thu, 25 Sep 2008 16:31:17 -0000 > On Tue, 2008-09-23 at 13:37 -0700, Jo Rhett wrote: >> 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. On Sep 25, 2008, at 7:53 AM, Tom Evans wrote: > Isn't this a non-pragmatic way of looking at this? Currently, as > long as > there are no serious issues with 6.4, 6.4 will be supported for 24 > months from release. This is abundantly clear from both prior history > and what secteam say. No, it's not. The secteam has repeatedly said that they don't know yet, and can't know yet, whether or not to support 6.4 for 12 or 24 months. This is the problem I am trying to solve. Guessing at this requires foresight, psychic abilities that nobody has. I believe it's a lot more pragmatic to simply say "we will support it for 24 months *unless* a major problem forces another release" and stop trying to be psychic. > To my mind, this entire discussion is bikeshed painting > that ends up with semantic arguing about what a 'final' release is. It's not semantics. It's a very serious issue with overlapping support periods that cause businesses to stay back on older releases, which means they contribute no resources to testing new releases. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness