From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 02:27:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CE63106567C for ; Wed, 18 Jan 2012 02:27:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5928FC1E for ; Wed, 18 Jan 2012 02:27:38 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0I2RakD098308 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 18:27:37 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F162E57.5020607@freebsd.org> Date: Tue, 17 Jan 2012 18:28:39 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Mark Saad References: <4F15B1AA.4020400@my.gd> <4F15C520.6090200@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:27:38 -0000 On 1/17/12 12:11 PM, Mark Saad wrote: > Here are My 2 Cents , > > 1. Support each release longer, or develop a better way to MFS ( Merge > from Stable ) bug fixes, and driver updates to RELEASE. It always > seams that there are a number of things in X-STABLE I would love to > have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE > just some new drivers and fixes . > > 2. Spell out the entire RELEASE road map at the beginning of the > release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc > . I think by the ".2" release of a line we should have some idea as to whether a particular lineage is going to provide a good basis for extended life. if for example we were to declare that 8 is really quite good, we might decide to declare it as having a longer life and allow 9 to die earlier as we go forward. I do understand the requirement for a stable basis for work but I can not say how many of the changes for newer hardware will get ported back. or by who. >