Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> For me our reluctance for any kind of change is a major demoralizing
> factor.
I hardly think we're "reluctant for any kind of change" --- the rate of
commits belies that. What we want is a convincing case that a proposed
change is an improvement over what we have. (You're entirely right that
there are plenty of dubious places in the existing code, but most of them
replaced nothing at all, and were thus improvements. To improve further
requires, well, clear improvement.) In the case of PD_ALL_VISIBLE,
I believe there is very serious reason to think removing it would be a
performance loss at least some of the time. We need proof it's an
overall improvement, not lack of proof it isn't.
> Having said that, I quite understand the reasoning behind the
> reluctance for change - we are a small community and can't afford to
> spend cycles spending on unnecessary regressions. But is that changing
> in the recent years ? I mean, aren't there a lot more developers and a
> lot more companies using/testing the new features/releases and
> reporting issues ?
Yeah, and a lot more fairly-new developers who don't understand all the
connections in the existing system. Let me just push back a bit here:
based on the amount of time I've had to spend fixing bugs over the past
five months, 9.2 was our worst release ever. I don't like that trend,
and I don't want to see it continued because we get laxer about
accepting patches. IMO we are probably too lax already.
In this connection I refer you to Sturgeon's Law(*): 90% of everything
is crud. Applied to our problem, it says that 90% of all patch ideas
are bad. Therefore, we should be expecting to reject a large fraction
of submitted patches. It distresses me that people seem to think the
default result for a submitted patch is that it gets committed. That's
backwards.
For a very long time we've tried to encourage people to submit rough
ideas to pgsql-hackers for discussion *before* they start coding.
The point of that is to weed out, or fix if possible, (some of) the bad
ideas before a lot of effort has gotten expended on them. It seems
though that less and less of that is actually happening, so I wonder
whether the commitfest process is encouraging inefficiency by making
people think they should start a discussion with a mostly-complete
patch. Or maybe CF review is just crowding out any serious discussion
of rough ideas. There was some discussion at the last dev meeting of
creating a "design review" process within commitfests, but nothing got
done about it ...
regards, tom lane
(*) The wikipedia entry is good enough. Whether Ted had the percentage
spot-on is not the key issue here.