From owner-freebsd-stable@FreeBSD.ORG Sat May 6 20:27:00 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 16A8416A403 for ; Sat, 6 May 2006 20:27:00 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAD8D43D5F for ; Sat, 6 May 2006 20:26:51 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so1062468pya for ; Sat, 06 May 2006 13:26:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QLn/aBYTej3ckPsWACCOQgqVfV2yWEe5yv1Y1tHIgXr4hFCmR8HG5UbTkdSwlVZcehZubvrtyLaY6+3bZ81sYYEcmgvydY20B2xnIjIOBR0X5oitjg22pLh0wHjgo66xr3SgS482zK0+VwQotMNbZTjxnpoGftUiymvok9jCFYs= Received: by 10.35.111.7 with SMTP id o7mr686887pym; Sat, 06 May 2006 13:26:51 -0700 (PDT) Received: by 10.35.29.20 with HTTP; Sat, 6 May 2006 13:26:51 -0700 (PDT) Message-ID: <3aaaa3a0605061326n2f18e38epf6b93f2042385cec@mail.gmail.com> Date: Sat, 6 May 2006 21:26:51 +0100 From: Chris To: "Mark Linimon" In-Reply-To: <20060505192152.GA17616@soaustin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <445B991F.3050600@rogers.com> <20060505192152.GA17616@soaustin.net> Cc: stable@freebsd.org, pjd@freebsd.org, linimon@freebsd.org, Mike Jakubik , kris@freebsd.org, rwatson@freebsd.org 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: Sat, 06 May 2006 20:27:00 -0000 On 05/05/06, Mark Linimon wrote: > Make Jakubik wrote: > > > FreeBSD users now demand stability and performance, as opposed to an > > influx of new bells and whistles just before the release [...] I fully > > understand that this is a volunteer project [...] > > I'm sorry, but the former statement proves the latter false. > > Let's try to do our Semi-Annual Refresher Course On Open Source Developme= nt: > > The developers (at least 99% of them) work for free. In their own spare > time. Their motivations vary but I don't believe any of those include > being in a position to feel they need to respond to demands. That's not > a positive motivator. If they wanted to be in that position, they could > just stay at their $realjobs for those extra hours. > > Part of their shared goals, however, is to turn out the best system that > they possibly can, in the hopes that people will find it useful and want > to contribute back to it. However, there are no guarantees involved, > implicit or explicit. (If you want to compare and contrast to how much > "guarantee" you get from closed-source development, please pull out a cop= y > of your EULA. They barely even "guarantee" that there are bits on the CD= .) > > There's a long process where the developers try to agree on what features > need to be included and what bugs need to be fixed. From the standpoint > of the people who attempt to coordinate this process, in technical jargon > the process is know as "herding cats". I would be able to serve as an > expert witness in court about this. (Side note: some of the cats hiss, > bite, and scratch; very few, if any, have _any_ interest in being herder.= ) > > There are always tradeoffs between stability and features. During the > 5.X cycle we managed in some degree to de-optimize both: we had features > that were only available in an "experimental" branch that some people > considered critical (wireless, anyone?) while that "experimental" branch > was unsuitable for production use. The idea was that we would hold on > to declaring 5.X "STABLE" until all the major bugs were fixed. > > And as a consequence, we didn't release for -- what, 2 years? > > So we've thrown out the idea of "wait until every possible bug is fixed." > It leads to rare releases, and larger code chaos, larger instability, and > allows FreeBSD's detractors to sniff "well, they're never going to releas= e > anything again." (Notice how the "BSD is dying" crowd on Slashdot has > been a lot quieter since we released 6.0?) > > So now what we're doing is trying to come up with more regular (not on > absolute deadline) releases, with smaller feature sets, to enable smaller > sets of new code to be debugged simultaneously. > > The features that some users see as critical, others don't. (I don't hav= e > quotas enabled; I have disabled soft-updates on the theory that as a sing= le > user I can trade longer startup time for possibly greater error recovery)= . > > > I wish i was a good Unix C programmer myself, so i could contribute in = a > > more direct way > > And there's the rub. The people who _are_ good Unix/C programmers are th= e > ones doing the work, and as such, feel that they have the final say about > what goes and what doesn't. While I hope that each of them will listen t= o > what individual users are saying, and take good suggestions to heart, the > fact remains that they are under no _obligation_ to do so. > > Finally, as has been pointed out already, the interactions between > quotas, soft-updates, and the rest of the system have problems that are > probably going to be fairly difficult to isolate and test. Thus, they > could take days, weeks, or months. If we were to hold the release until > these were fixed, basically our last 2 months of QA would be out the > window. This is not a way to keep developers happy; at some point they > will tire of the inability to work on the things that they find interesti= ng, > and wander off to find something else more fun to do. > > Summary: it's too bad that there are regressions, but sometime they're > a fact of life. If these regressions are in areas that are critical for > a certain user, that user should just skip 6.1 and wait for 6.2. The > stability gains that 6.1 have over 6.0 in so many other areas means that > it's time for 6.1 to go out the door, because for the majority of users > it's going to be a big win. > > As always, we welcome test cases on e.g. non-critical systems, earlier > in the release process (or between releases), where there's enough time > to thoroughly test that any proposed fix doesn't cause more problems than > it cures. Within a few days of release, that simply isn't the case right > now. > > mcl > _______________________________________________ nice post and ultimately you are correct, I personally would prefere a higher gap between releases for the following reasons tho. 1 - it does increase stability if the extra time is spent fixing bugs and testing the fixes. 2 - its easier for administration, upgrading freebsd every 2 to 3 months isnt ideal for administrators. I know releases are supported for much longer but given what kris told me recently that ports are only supported on the very latest release I found that a bit worrying. 3 - it raises profile for the release, the euphoria surrounding a release is much less if there is one every other month. In terms of a new major version ie. 7.x over 6.x I think that should only be released when their is something major changed like 5.x over 4.x had a new filesystem smp support etc. and 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.=20 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. 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. 4 - new features in minor version, why are we discussing an issue where there isnt enough time to fix some bugs but there is enough time to add java to the base system, something that has the potential to cause new bugs as well. 5 - bug reports not acknowledged. I have submitted a PRs myself and none have even been acknowledged and I suffer from the bge problem in 6.x and I wonder if its resolved in 6.1 or thats another bug which compromises stability that will be in a RELEASE. Ultimately RELEASE is supposedbly the stabliest 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. After my rant I will say 6.1 so far has proven to me a lot more stable then 6.0 which shows the amount of hard work gone into it has made a difference and I thank everyone involved for the work they do, I just wonder how many share my views thats all. I am a hardcore freebsd supporter and will continue to use in all my servers. Chris