From owner-freebsd-stable@FreeBSD.ORG Wed Sep 17 23:33:48 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 15F261065676; Wed, 17 Sep 2008 23:33:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C3BCF8FC1E; Wed, 17 Sep 2008 23:33:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 5D46146B2E; Wed, 17 Sep 2008 19:33:47 -0400 (EDT) Date: Thu, 18 Sep 2008 00:33:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , Wesley Shields , Nathan Way , Ben Kaduk Subject: Re: Upcoming Releases Schedule... 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: Wed, 17 Sep 2008 23:33:48 -0000 On Wed, 17 Sep 2008, Jo Rhett wrote: >> On Mon, 15 Sep 2008, Jo Rhett wrote: >>> Robert, I'd like to point out to you that when I complained about 6.2's >>> accelerated EoL, I was soundly boxed around the ears and told that I >>> should have been paying attention to the projected EoL date when we >>> decided to roll out 6.2 across the business. >>> >>> Now you are saying that expected EoL will be determined at some random >>> point in the future based on gut feelings about how well a completely >>> different branch is doing. >>> >>> How can I reconcile these disparate points of view? How does one focus on >>> testing and upgrade cycle for an "appropriately supported release" when >>> the decision for the support cycle is completely up in the air? >> > On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: >> The FreeBSD Project, as with any other company or organization, responds to >> events as they occur. We try to plan ahead, and when things go better or >> worse than expected, we sometimes change the plans. As far as I know we've >> never *shortened* the expected support timeline for any branch or release, >> but we have on occasion lenthened them when we feel it's important to do >> so. I'm not sure what other answer is possible. > > No other answer. But nobody has yet provided what the EoL period is going > to be. I have no problems with a period being extended ;-) But the > business needs to know the minimum EoL for a given release to determine if > upgrading to that release is viable. Well, a starting answer is the policy found on http://security.FreeBSD.org/: 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. At the time of release, we know if a release is considered "early adopter", and attempt to clearly mark it as such. The harder question is whether or not we will start out considering a release "normal" or "extended" -- sometimes we are able to make that decision at the time of the release (i.e., we believe firmly it's the last release on the branch at the time of release), but on the whole we will make that decision based on the facts on the ground. An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently, and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. Robert N M Watson Computer Laboratory University of Cambridge