Date: Sun, 7 May 2006 09:30:09 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Chris <chrcoluk@gmail.com> Cc: stable@freebsd.org Subject: Re: quota deadlock on 6.1-RC1 Message-ID: <20060506233009.GF720@turion.vk2pj.dyndns.org> In-Reply-To: <3aaaa3a0605061326n2f18e38epf6b93f2042385cec@mail.gmail.com> References: <445B991F.3050600@rogers.com> <20060505192152.GA17616@soaustin.net> <3aaaa3a0605061326n2f18e38epf6b93f2042385cec@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2006-May-06 21:26:51 +0100, Chris wrote: >1 - it does increase stability if the extra time is spent fixing bugs >and testing the fixes. It always winds up not working this way. People won't test the early beta releases and when the final release candidates appear, people suddenly insist that X is a show-stopper - even (or especially) if they haven't previously mentioned it. Scott has written at length about this problem. >2 - its easier for administration, upgrading freebsd every 2 to 3 >months isnt ideal for administrators. I have this problem at work. But there's nothing to say that you have to upgrade to every minor release. >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. IMHO, 5.x demonstrates why this is a bad idea. The number of new features made getting them stable extremely difficult. And the differences between 5.x and 4.x meant that it was getting incresingly difficult to merge fixes from 5.x to 4.x. This was the prime reason why the FreeBSD project decided to go for more releases with smaller deltas between releases. >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 demonstrates the difficulty of handling multiple major feature changes in a release. Similar problems occurred with 3.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. Java _isn't_ part of the base system (and never will be). The work on Java is being done by a different group of people and hasn't impacted the main FreeBSD release at all. The recent certification of the FreeBSD Java port is the culmination of several years of effort. >5 - bug reports not acknowledged. I have submitted a PRs myself and >none have even been acknowledged Do you mean that you haven't received the GNATS acknowledgment or that you haven't heard anything further? Does your PR include a patch (or even sufficient detail to enable the problem to be reproduced)? Did you bother to talk to any of the developers about your problem? In any case, the time to bring this up is _not_ after the final release candidate has been cut. > 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. Did you bother testing the beta and RC releases to check for yourself? >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. This is plain ridiculous. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060506233009.GF720>