From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 16:48:43 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 71E33106568C; Mon, 15 Sep 2008 16:48:43 +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 55C618FC15; Mon, 15 Sep 2008 16:48:42 +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 m8FGm5HL014458; Mon, 15 Sep 2008 09:48:06 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.438] Message-Id: <17B9E874-88E0-4DBF-8525-D6FF11FCBAD1@netconsonance.com> From: Jo Rhett To: Ben Kaduk In-Reply-To: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> 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:48:00 -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: Nathan Way , Wesley Shields , freebsd-stable 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 16:48:43 -0000 On Sep 5, 2008, at 1:19 PM, Ben Kaduk 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. > Extended > Selected releases will be supported by the Security Officer for a > minimum of 24 months after the release. > > I don't remember seeing any speculation about 6.4 being an extended > release, so, EoL is 12 months after release, whenever that actually > happens. Okay, so 6.3 will EoL at roughly the same time as 6.4. Why should anyone spend any effort on 6.4? > That's the difference between a long-term-support branch and a > regular branch; > many OSes do that. If you want to run the same machines for a long > time and > not have to do a huge battery of tests (at the expense of getting > new features > and better performance in the interim), you use long-term branches. > The regular branches that get released later, will then become > unsupported > at the same time as the (older) long-term branch. > > Yes, it's poor when a long-term branch goes EoL before there's > another one > ready to take its place, but if the new one isn't ready, then you > just use > whichever regular release is current and then snag a long-term release > when it becomes available. Yes, it's more work, but that's life. Is it just me, or does this make no sense at all? This does make it clear to me why the release team can't find the resources to do longer support. Who can convince their company to put resources into the mainstream release effort, when this kind of cycle basically forces every company to run their own internal release process. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness