From owner-freebsd-stable@FreeBSD.ORG Sun May 7 08:02:02 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A509716A404; Sun, 7 May 2006 08:02:02 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44DFE43D46; Sun, 7 May 2006 08:02:02 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 85EFC2E9B; Sun, 7 May 2006 03:02:01 -0500 (CDT) Date: Sun, 7 May 2006 03:02:01 -0500 To: Chris Message-ID: <20060507080201.GA15703@soaustin.net> References: <445B991F.3050600@rogers.com> <20060505192152.GA17616@soaustin.net> <3aaaa3a0605061326n2f18e38epf6b93f2042385cec@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3aaaa3a0605061326n2f18e38epf6b93f2042385cec@mail.gmail.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: stable@freebsd.org, pjd@freebsd.org, linimon@freebsd.org, Mike Jakubik , kris@freebsd.org, rwatson@freebsd.org, Mark Linimon Subject: Re: quota deadlock on 6.1-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2006 08:02:02 -0000 On Sat, May 06, 2006 at 09:26:51PM +0100, Chris wrote: > 1 - it does increase stability if the extra time is spent fixing bugs > and testing the fixes. This assumes that you can persuade committers to focus on bugfixes instead of on other things that they consider more fun. > I happen to think because 5.1 and 5.2 werent STABLE the 5.3 STABLE > release turned out very stable at least in my experience and was more > stable then 6.0. This is the opposite from what most people experience, at least from my experience with the mailing lists and GNATS. 5.3 was somewhat rough, due in part to a large number of things merged into it during the QA cycle. 5.4 was a substantial increase in stability vs. 5.3 without having that many new features. 6.0 had a fair number of advances in the code but by the time it was released, most of the developers had turned their attention away from 5.X and to 6.X. Thus, many people found that not only did 6.0 have more features, it also had had more testing, and a large degree of stability. There were certain cases where things did not work as well as we would have liked; however, for quite a number of people, 6.0 worked better than even 5.4. 6.1 incorporates a large number of fixes more oriented to stability than features. 5.5 incorporates a subset of those, because of the infeasbility of back-merging many of those changes (they would risk more instability). > What was major difference between 6.0 and 5.4? if I understand it > correctly their has been a lot of work done fixing problems that > existed in 5.x but no new feature to shout about. Much of the work was done on internals, which will fix race conditions, increase performance, and add stability in the long run. In particular, the wireless support in 6.0 is (AFAICT) much more advanced than 5.4. > ULE which was unfinished in 5.x still remains unfinished in 6.x and I > wonder if will be a unfinished feature in 7.x. This is completely tangential to the other issues. ULE to some degree is still a research project. If you are not willing to live on the bleeding edge of testing, you probably do not need to be running ULE. > 4 - new features in minor version, why are we discussing an issue where > there isn't enough time to fix some bugs a) there is never enough time to fix all the bugs. b) fixing bugs relies entirely on developer interest. The 5.X experience proved that longer release cycles do not necessarily raise developer interest. > 5 - bug reports not acknowledged. I have submitted a PRs myself and none > have even been acknowledged If they have not been acknowledged by GNATS, you need to email bugmaster@FreeBSD.org and point these out so that we can identify the problem. (If your email has no reverse resolution, your email will not make it to GNATS). If they have been acknowledged by GNATS, then you should understand there there are currently 5,424 PRs in the system (984 are ports PRs; many others are kern/ or bin/). We have far more PRs arrive than we have developers who are willing to spend time working on them. (The arrival rate is somwehere around 40-50/day, 3/4ths of which are ports PRs and can be cleared somewhat more quickly.) If you have any concrete suggestions on how we can get more current developers interested in working on PRs, or some new developers that are primarily interested in working on PRs, please make them. I have been trying to come up with suggestions for a while and haven't come up with much of anything. > Ultimately RELEASE is supposedly the stablest branch. Yet due to a > rush to push out a release to keep people like slashdot happy people > running freebsd servers around the world will suffer problems because > of these bugs and may possibly move to linux as a result. When are we > going to go back to a FreeBSD that just works. Keeping the slashdot crowd happy is merely a side-effect of making releases that fit most user's needs, and in a timely fashion. We have definitely erred in not making them in a timely fashion in the 5.X series; arguably, the push to wait until 'all promised features were complete' failed to meet most users' needs as well. The FreeBSD that "just worked" was release 9 or 10 out of a series that was a far simpler codebase than the current one which runs on systems with ACPI, multiple processors, multiple architectures, and a much larger number of motherboards and peripherals. We are currently ready for release 1 out of the 6 series. If you compare 6.1 to 4.1 you'll find that there is absolutely no comparison at all. > After my rant I will say 6.1 so far has proven to me a lot more stable > then 6.0 Well, this is where the "rubber meets the road" as the expression goes. This seems to be the common experience. (There are certain users who seem to have problems with 6.0/6.1; these seem to be in the minority, and possibly depend only on certain workloads.) And, in addition, most users seem to feel that 6.X is both more feature-complete, and more stable, than 5.X. We continue to do the best that we can; IMHO we make amazing progress with a small number of developers, on a large number of architectures, on several code branches simultaneously, on a bewildering variety of motherboards and peripherals. But we're not going to satisfy everyone. mcl