From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 17:00:22 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 708A11065682; Mon, 15 Sep 2008 17:00:22 +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 53B7B8FC12; Mon, 15 Sep 2008 17:00:22 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m8FGxh78014764; Mon, 15 Sep 2008 09:59:43 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.436] Message-Id: <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> From: Jo Rhett To: Robert Watson In-Reply-To: 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: Mon, 15 Sep 2008 09:59:38 -0700 References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> X-Mailer: Apple Mail (2.928.1) 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: Mon, 15 Sep 2008 17:00:22 -0000 On Sep 6, 2008, at 4:06 AM, Robert Watson wrote: > Unfortunately, it's a little hard to tell at time-of-release whether > a particular release will become extended life or not. This is > because extended support status is dependent on the success of the > release ... > from earlier branch adopters. How long we keep release 6.x releases > will depend entirely on how successful 7.x is; I think there's a > reasonable expectation that 6.4 or 6.5 will be the last 6.x release, > in which case we would want to grant it extended support status. > But what happens depends a lot on how successful 7.1 is. My hopes > are high, but there's nothing like real-world deployment to shed > light on things :-). 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. I was also told that I should have been more active in the release cycle process for 6.3, etc. 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? How does one talk to management about getting resources assigned to help with the freebsd release testing process, when one cannot make any valid predictions for that release will even be supported long enough to justify the effort involved in upgrading? What you are saying is completely reasonable from a developers point of view. But those of us who use freebsd in an environment which requires extensive testing and long-term planning for support have trouble with this. In short, I can't imagine how I could possibly make any business case to get support for helping the freebsd dev/rel process at all. Why? Because frankly we're going to be forced to run our own internal release management process instead. I guess this is not surprising, as this appears to be what every other business using significant amounts of freebsd in production are doing today. My point to you is that if this wasn't being forced upon every company that uses FreeBSD, those companies could commit more resources to help the core (main branch, whatever - not "Core") freebsd development. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness