Date: Tue, 17 Jan 2012 15:50:38 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <4F16094E.2080108@FreeBSD.org> In-Reply-To: <CAJ-VmomM46xGk3R6a9G_KDxMvF5ETiSQPwv5ARxwBo90t4=x=g@mail.gmail.com> References: <alpine.BSF.2.00.1112211415580.19710@kozubik.com> <CAJ-VmomM46xGk3R6a9G_KDxMvF5ETiSQPwv5ARxwBo90t4=x=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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? 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. > ... 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. > ... 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? What I'd like to see us do is to rethink what a "release" is. In particular, I'd like to see us start to do more point releases (e.g., 8.2.1) which involve only updates to the base, and don't involve the whole ports and doc machinery. This would combine the current patch releases done for security purposes. Ideally of course we'd have a branch were known-good stuff was merged from the -stable branch, so an 8.2.1 wouldn't (necessarily) be what's in stable/8 at the time. However I'm not sure we have the personnel for that, so even doing stable/8 -> 8.2.N would be an improvement over what we have. One area where user involvement *would* be really welcome here is in the area of regression testing. It would be much easier to cut a point release if we had a series of regression tests, submitted by users so as to reflect real world conditions, that we could run against the new version. That way we could at least be sure that we didn't break anything that current users of that branch are relying on. Several people have mentioned 3x/year as a good release schedule, I don't see any reason why we couldn't do point releases in that timescale. The other thing I think has been missing (as several have pointed out in this thread already) is any sort of planning for what should be in the next release. The current time-based release schedule is (in large part) a reaction to the problems we had in getting 5.0 out the door. However I think the pendulum has swung *way* too far in the wrong direction, such that we are now afraid to put *any* kind of plan in place for fear that it will cause the release schedule to slip. Aside from the obvious folly in that (lack of) plan, it fails to take into account the fact that the release schedules already slip, often comically far out into the future, and that the results are often worse than they would have been otherwise. Meta-note, there is going to be a strong knee-jerk reaction to that last paragraph to the effect that I'm attacking individuals who are involved in the release process. I'm not. The *system* is deeply flawed, so the heroic efforts of those doing their best to make that system work are in vain. That's tragic for all concerned, including those who've given so generously of their time and effort. I tried to make the point back in June that there was no reason to cut 9.0-RELEASE yet because we don't have solid support for clang in either the base, or ports (amongst several other reasons) and that the delay for getting that working would be a great "excuse" for slipping the support schedule for 8 so that we could release 9.0 not-too-long before 7 was about to go EOL, and make the 8/9/10 release schedules fit the new, (hopefully) more rational model. Perhaps we can reconsider that idea for 10.0. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F16094E.2080108>