Re: Two weeks to feature freeze

On Tue, 24 Jun 2003, Dann Corbit wrote:

> > -----Original Message-----
> > From: The Hermit Hacker [mailto:scrappy(at)postgresql(dot)org]
> > Sent: Tuesday, June 24, 2003 6:10 PM
> > To: Dann Corbit
> > Cc: The Hermit Hacker; Jan Wieck; scott.marlowe; Bruce
> > Momjian; Tom Lane; Jason Earl; PostgreSQL-development
> > Subject: RE: [HACKERS] Two weeks to feature freeze
> >
> >
> > On Tue, 24 Jun 2003, Dann Corbit wrote:
> >
> > > I did something about it. I raised the issue.
> > > Is it really so that whoever it is that raises a question
> > is also the
> > > one who must fix the issue raised? A strange model indeed.
> >
> > Its worked for us ...
> >
> > Wait, I know what should make you happy ... it won't get
> > anytihng done, but ...
> >
> > Bruce, can you add "* Improve Testing" to the TODO list
>
> It is surely a titanic mistake to bring up any issue on this list if you
> do not plan to fix it yourself.

No, it's not. But you have to realize that when you bring up a "problem"
without a solution, you are, in effect, asking someone else to solve your
problem. I do that all the time. I don't code postgresql (well, I've
hacked around in it a bit for fun, but most of it is over my head.)

So, then I bring up something (like the screwy date mangling / parsing
misfeature we've been discussing this last week) I KNOW I'm asking the
programmers for a favor to fix it, and I know that if they all said, no,
we don't have time to fix it, if you want it done you'd better get
hacking, then I can either get hacking or wait until someone has time to
fix it.

I.e. I have to be civil and present my case in a convincing enough manner
to get someone else to do it.

The bigger the change, the more likely it is that it'll get thrown back at
the person suggesting it.

A prime example is using a threaded model. About every three months or so
someone shows up waving their hands about how Postgresql just can't be
fast without threads. No code, no benchmarks, no proof, just a rough
feeling they got from reading a magazine article. Invariably, the issue
is far more complex than just "make Postgresql threaded" and the person
suggesting it can "justify" why someone else should spend months doing it,
but they can't be bothered themselves.

In the Open Source universe, if you want a feature, you have to be willing
to "pay for it." Whether that's with code or a checkbook, either way,
TANSTAAFL.

In the case of better testing, if you're willing to get out your checkbook
and start pumping out cash to a few of the developers here on the list,
I'd sure someone would jump right up and start writing your test suite.

Or, you can code it yourself.

Or, you can convince someone that the testing is necessary and they'll
volunteer their time.

For me, more testing would gain me nothing. I already test postgresql on
a test box before throwing it into production. I test it for load,
response, correctness, etc... and if I miss something, it's usually a
pretty small issue, and it gets fixed fast.

I'd much rather see time and effort go into the things they go into, like
optimizing the query planner, in() with subselects, full text indexing,
and many other things.

There is a finite pool of hacker skill poured into Postgresql, and pouring
more of it into testing means less gets poured into development, and right
now, I've got all the testing I need, as do most of the developers and
users I know.

Open Source works because some scratches and itch. right now, you're the
only one with an itch for more testing. If you don't scratch it, it
likely won't get scratched any time soon.

who knows, in a year, maybe someone else will get the itch and scratch it.
But your arguments have been unconvincing, since the reality of Postgresql
is that it is the absolutely most reliable database I know of, and has one
of the fastest turnaround times for bug fixes when they do pop up.

Does apache have a comprehensive test suite? Not that I know of. Neither
does the Linux kernel or the BSD kernel. But, they all get the job done
better than their commercial counterparts with far less headache.

This discussion hasn't been a complete waste of time, but your arguments
have bordered on insulting to those of us who currently DO the testing on
our own machines. You've dismissed our testing out of hand on several
occasions as insufficient, when at least we ARE testing postgresql, even
if it doesn't meat up to your higher standards.

If you want to raise the bar, then YOU get to raise it.