Re: Rule updates and PQcmdstatus() issue - Mailing list pgsql-hackers

> -----Original Message-----
> From: Ross J. Reedstrom [mailto:reedstrm@rice.edu]
> Sent: Monday, September 09, 2002 12:26 PM
> To: Dann Corbit
> Cc: Rod Taylor; Steve Howe; PostgreSQL-development
> Subject: Re: [HACKERS] Rule updates and PQcmdstatus() issue
>
>
> 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?

I do have friends who work in Q/A.

> _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.

I have been programming since 1976 on literally many dozens of projects.
There is no project on which I have been a part where such a thing would
be allowed.  On the other hand, the projects I tend to work on are the
"these tools are used to run your business" MIS sorts of things.
Perhaps other areas of development are different.
> > With open source projects, the emphasis 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.

If this particular case is a case of someone relying on undocumented
behavior, then there is no bug.  If this is a case of relying upon
documented behavior and the behavior changes, then there is a bug.
> <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.

There are very serious problems that have been in the release notes for
a very long time and yet have never been addressed.  Most of them are
rather esoteric and won't affect most users.  I have been on many
projects that were far more concerned with correctness.  As I have said,
"no serious bugs are allowed in a release" is not uncommon on the
commercial projects where I have experience.  That includes 9 years as a
subcontractor at Microsoft.  If they have a serious bug that cannot be
fixed, they will simply cut scope.  But my experience was on MS (ITG)
projects.  Perhaps other branches of MS did not require the same rigor.
On the other hand, PostgreSQL is more responsive in this area than any
other open source project that I know of.

> 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.

This may be an example where the original poster is asking for something
they should not be asking for.  If the original poster was relying upon
undocumented behavior, then there is nothing that needs to be done, and
the resulting problem is the original poster's fault.
> 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.

You are probably right about this case.  In fact, I am not defending the
original poster's demand.  I have no idea if their request has merit or
not.  I was merely expressing an opinion that a good standard to follow
is to fix all outstanding showstopper bugs before making a release.
Nothing more, nothing less.

I am not attacking the PostgreSQL project or team.  In fact, I think it
is the finest piece of open source, freely available software on the
planet.  My request was more of an aside -- simply wishing out loud for
an intense focus on fixing problems.