Pavan Deolasee <pavan.deola...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers