From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 18 02:56:47 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 DA9F41065673; Wed, 18 Jan 2012 02:56:46 +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 B33B08FC08; Wed, 18 Jan 2012 02:56:46 +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 q0I2ui2J098421 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 18:56:45 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F16352B.3020008@freebsd.org> Date: Tue, 17 Jan 2012 18:57:47 -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: Doug Barton References: <4F16094E.2080108@FreeBSD.org> In-Reply-To: <4F16094E.2080108@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Adrian Chadd 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:56:47 -0000 On 1/17/12 3:50 PM, Doug Barton wrote: > First, let's do away with the whole, "If you step up to help, your help > will be accepted with open arms" myth. That's only true if the project > leadership agrees with your goals. "leadership" doesn't really control development here. action does. > We also need to take a step back and ask if throwing more person-hours > at the problem is the right solution, or if redesigning the system to > better meet the needs of the users *as a first step* is the right answer? > careful, you are starting to sound reasonable there.. > On 01/17/2012 15:01, Adrian Chadd wrote: >> .. I'm replying to the OP because honestly, this thread has gotten a >> bit derailed. >> >> If you'd like to see: >> >> ... more frequent releases? then please step up and help with all the >> infrastructure needed to roll out test releases, including building >> _all_ the ports. A lot of people keep forgetting that a "release" is >> "build all the ports for all the supported platforms". > Does it need to be? I've been pushing a long time now to have a branched > ports tree. If we have a "stable" version of the ports where only > known-good changes are promoted then that frees us up quite a bit to > redefine what a "release" is. that's another 'man hours' problem (branched ports) >> ... longer lifecycle? Then please step up and contribute patches for >> features for your favourite branch. As a developer doing this in my >> spare time I'm only really working on new features on -HEAD and maybe >> backporting fixes to 9.x. What _I_ would like is someone to take on >> the task of testing and backporting net80211/ath fixes to 8.x and 7.x. > So you want to do all the fun stuff, and have someone else do your scut > work? Good luck with that. :) Maybe what we need to do is redefine what > it means to be a FreeBSD committer. "From now on, your commit bit comes > with XYZ privileges, but also ABC responsibilities." Sure, we'd lose > some people, but what would we gain? > > Also, your premise is flawed. We (speaking generally) suck at supporting > more than one -stable branch. We *really* suck at supporting three. Six > months ago when the machinery was just beginning to spin up for > 9.0-RELEASE I tried to get the PTB to reconsider. I was told that my > concerns were invalid because it was basically ready to go as is. > > The plan I laid out at the time was to have no more than 2 stable > branches extant at any given time. Lengthen the periods where each > stable branch is supported, and terminate the oldest one when the newest > one is released. > I certainly think 9.0 was premature.. 8.x just started.. this should have been 8.3. >> ... longer branch lifecycle? Same as above. None of the developers are >> going to reject bugfixes and backported drivers to a legacy, stable >> branch. We may be a bit against the idea of porting entire new >> subsystems to legacy, stable branches - but if there's a good enough >> reason _and_ it's been tested _and_ there's a need for it - _I_ >> wouldn't say no. > But committers already fail to MFC *existing* bug fixes to stable > branches (even ones they generated). This is especially true for the > older branches. So how is the idea of users generating more new bug > fixes going to help? usually it's because they just forgot..