On Fri, 2006-03-17 at 03:08 -0500, Mike A. Harris wrote: > Leslie Satenstein wrote: > > With kudzu broken, potential keyboard problems, as well as the 2054 > > kernel for nvidia, I see no reason to download the first release. > > Why push broken software unless a new iso in a very short time > > thereafter(2 weeks) is released. > > That's easy enough to answer. All software has bugs in it, or at > a bare minimum - most software does. The software included in > Fedora Core is no exception, and never has been. Every single > OS release ever made by Red Hat, or for that matter by Debian, > SuSE, Mandrake, Sun Microsystems, Microsoft, Apple, or any other > OS or distribution you could care to name, has shipped software > which contains bugs. > > Some of the bugs are minor, while other bugs are larger in impact. > Bugs are a simple fact of life in computer software, and there's > really no alternative than to live with that fact. > > It is entirely possible in theory, to delay any of the above > operating system's release dates, to then "go and fix that one > more critical bug", but after doing so, there is at least 1, and > more likely 100 or more other "critical" bugs that aren't fixed > also. Why not fix them too? > > The reason why, is that you then delay your OS release by another > 2 weeks, then another, then a month, and eventually Debian users > start chastizing you for trying to clone the Debian release model. > > That was a joke. Ok, only partly a joke. > > Seriously though, the release just gets delayed and delayed, and > one user after another jumps on the bandwagon claiming "You fixed > critical issue #12345, but *MY* issue which is obviously much > worse of a problem is not fixed! You must delay and fix my issue > also!". After 1000 users do this, you end up not releasing an > operating system ever period, because there is _always_ another > critical bug left in the OS. > > There will _always_ be bugs in the OS which are frustrating to > someone out there. Always be bugs to which someone can't believe > we could possibly have been so careless to release the OS without > fixing at _least_ that one issue. But again, there isn't one > person out there thinking that. There are 10000 people out there > thinking that, and each of them is thinking about a different issue. > > Delaying the OS to fix every bug that "someone" out there will > be frustrated about, or shocked senselessly that we could possibly > have released without delaying to fix their issue, really _DOES_ > mean "Never ever ship an OS ever." > > That is just a straight fact - wether or not everyone accepts it > or not. The OS _WILL_ always ship with bugs, some known ahead > of time, and others discovered after the fact. At a certain > point you either ship the OS, bugs and all, or throw in the > towel. > > > > Suggest a core5.01 version that has the bugfixes for nvidea, keyboard > > and for kudzu. > > By all means, please feel free to create your own custom ISO images > with whatever fixes you'd like to have in them after they're released. > The Fedora project encourages users to customize the distro, and that > includes making custom bug-fixed ISO sets if desired. > > > > Sorry to be against the release. But a reputation for quality is at > > stake. I do not want to tell others, "The Core 5 cd's that are in the > > books and magazines are faulty" Do not use them, do not purchase the > > book or magazine. > > > > Better to be 4 days late, have the fixes, then to ship a faulty product. > > That's where you're wrong. This release is no different than FC4, FC3, > FC2, FC1, any RHL release, or any RHEL release. All OS releases have > bugs in them as I've stated above. Some more severe than others, but > that is just a fact of life. If FC5 contains an out of the box bug > which completely prevents you from using the OS, that is unfortunate, > but it will likely work for many other people. Fixing your favourite > 3 critical must-have-fixed bugs, may fix the OS for you, and a handful > of other people also, but then there will be 1000 other critical bugs > that are not fixed which cause the same grief for other people as you > are potentially seeing. Should we stop-ship the OS and _just_ fix > the bugs you care about? Or should we stop-ship the OS and fix _ALL_ > critical bugs that _anyone_ cares very strongly about? > > Stopping shipping for one person, or even a few people is not a viable > option, and isn't fair for everyone else out there who has equal or > worse problems. Stopping shipping for everyone with a serious problem, > until all such problems are fixed, means delaying the OS for weeks, > or months - most likely years, or never actually ever releasing the > OS again ever. Plus, while those "critical bugs" are being fixed, then > all of a sudden the new upstream release of GNOME comes out, and someone > else wants that included too, since the release is delayed anyway! > Then there's a new upstream release of openoffice which fixes a lot > of bugs, might as well include that too. Then X11R7.1 comes out, then > a new upstream kernel, then KDE, then gphoto, then .... you get the > idea. > > All new OS releases are going to have instabilities. Get used to that, > because it is reality, and reality isn't going to vanish any time soon, > wether the OS release date is delayed to fix an issue or two or not. I am not sure if this was already said?:: =========================================================================== The Release manager plays a major role in deciding when the OS is ready to ship. We should encourage the users and developers to find/report/fix bugs. When the product is ready it is ready. In a competitive world the winner has optimized the following: --- Time to market --- Quality --- Stability --- Performance --- Marketing Genius (Eye candy appeal, etc...) --- Customer support =========================================================================== So, let the users complain. The FC5 team will deliver a good product, I hope :) Thanks, Ernesto > > > > > -- > Mike A. Harris * Open Source Advocate * http://mharris.ca > Proud Canadian. > -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list