From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 21:56:09 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 C272C106564A for ; Mon, 22 Sep 2008 21:56:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC588FC29 for ; Mon, 22 Sep 2008 21:56:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 22764 invoked by uid 399); 22 Sep 2008 21:56:08 -0000 Received: from localhost (HELO ?192.168.0.12?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Sep 2008 21:56:08 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48D81476.4050309@FreeBSD.org> Date: Mon, 22 Sep 2008 14:56:06 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jo Rhett References: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <20080920020703.GA82392@phat.za.net> <851F09A2-788D-4343-9E00-A0AB5C3AC063@netconsonance.com> <20080920044148.GA60230@in-addr.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Upcoming Releases Schedule... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 21:56:09 -0000 Jo Rhett wrote: > On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote: >> Or to put it another way, what to you is "support" in terms of >> FreeBSD releases. As far as I am aware, if you stick on a >> RELENG_X_Y_Z_RELEASE tag >> then the most you get is security fixes. No new features, >> no new drivers, no bugfixes. So if I am interpreting things >> correctly, you are asking for security fixes to be ported to >> RELEASE tagged branches for longer? > > That is what I and my $EMPLOYER want yes, although as I said I am > willing to support other efforts. (ie I am unlikely to be the > difference between make or break on this effort, so if more support was > something that got other businesses involved enough to achieve that > change, then....) Just to be clear, what you are interested in is a longer support period for security patches to be merged into a branch such as RELENG_6_3 (which only has security fixes applied to it now). Is that correct? Assuming that I'm correct on that assumption, I would suggest that you gather a community of people who share a similar interest and quite simply do the work. It should be pretty obvious based on any given security advisory what will need to change, and if you get enough people involved there won't be that much work for any one person or company. There is even a mailing list for this sort of thing, freebsd-eol. It's not very active right now, but that doesn't mean you can't change that. As Robert pointed out, project history is such that those who identify a given need and fill it are generally "absorbed" into the "official" canon as it were, so at some point in the future you (pl.) might actually become part of the answer to the "more resources" questions that you keep insisting on an answer to. I'd also like to point out that there is another chicken-egg problem that has been glossed over in this thread. You have said many times that it's hard for a company to devote resources to testing a given release candidate without knowing in advance how long that release will be supported. Several people (including Robert, who is part of the release team) have said that we can't make a firm conclusion on how long a given release will be supported until we have a pretty good idea how "successful" a given release will be, which requires people actually testing and using it. Do you see the problem? Finally I would like to suggest that everyone interested in the problems of supporting releases for longer than their announced EOL to please take that discussion to the freebsd-eol list. AFAICT it isn't really on topic for -stable. hth, Doug -- This .signature sanitized for your protection