Date: Tue, 17 Jan 2012 18:57:47 -0800 From: Julian Elischer <julian@freebsd.org> To: Doug Barton <dougb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Adrian Chadd <adrian@freebsd.org> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <4F16352B.3020008@freebsd.org> In-Reply-To: <4F16094E.2080108@FreeBSD.org> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <CAJ-VmomM46xGk3R6a9G_KDxMvF5ETiSQPwv5ARxwBo90t4=x=g@mail.gmail.com> <4F16094E.2080108@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F16352B.3020008>