On Mon, Sep 09, 2002 at 11:30:52AM -0700, Dann Corbit wrote: > > > > I suspect it'll be several more major releases before we > > begin to consider it approaching completely functional. > > I believe that the surprise is at the focus, when it comes to a release. > With commercial products (anyway) if you have any sort of show-stopper > bug (crashing, incorrect results, etc.) you do not release the tool > until the bug, and all others like it, are fixed. Bugs that have to do > with appearance or convenience can be overlooked for a release as long > as they are documented in the release notes. Now, it is not unlikely > that there are unintentional show-stopper bugs that get through Q/A. > But intentionally passing them through would be incompetent for a > commercial enterprise.
Hmm, you don't have any drinking buddies who work QA, do you? _Lots_ of known, "eat your harddrive" bugs get classified as "to be fixed in future release" in commercial software, when the release date pressure grows. > With open source projects, the empasis tends to be on features, with far > less regard for correcting known problems. Even bugs that can cause a > crash seem to be viewed as acceptable if they happen rarely. Huh? I tend to see exactly the opposite. Actual crash and "wrong answer" bugs tend to get very prompt attention on all the open source projects I know and use. What _does_ get delayed or even ignored are "bug compability" problems, like this one. That is, software that relies on the "affected rows" count is in fact broken, since it's making assumptions about that number that were never promised in any standard or interface docs. <snip silly comparison to commercial software house> > All kidding aside, I would like to see increased emphasis on stability > and correctness. But I will admit that it is a lot less fun than adding > new features. And this has got to be trolling: PostgreSQL is one of the _most_ stability and correctness focused software projects I've ever known. In this particular case, the complaints about this issue where "Your bugfix broke my tool! make it better!" The answer was "We can't just put it back, that's an actual bug in there (rules firing in an unpredicatable order). What's the _correct_ behavior?" The people with the complaints then did not come up with a compelling, complete description of what the correct behavior should be. There's always been vague parts to the "desired behavior" like the phrase Tom pointed out: "in the context of the view" which was clarified to mean "viewable by the view", which is nearly impossible to code, if not an example of the halting problem. PostgreSQL as a project errs on the side of not coding the quick fix, in favor of waiting for the right answer. Sometimes too long, but this case isn't one of those, IMHO. Ross -- Ross Reedstrom, Ph.D. [EMAIL PROTECTED] Executive Director phone: 713-348-6166 Gulf Coast Consortium for Bioinformatics fax: 713-348-6182 Rice University MS-39 Houston, TX 77005 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
