On Tue, Jan 22, 2013 at 7:57 AM, Phil Sorber <p...@omniti.com> wrote: > On Mon, Jan 21, 2013 at 8:47 PM, Josh Berkus <j...@agliodbs.com> wrote: >>> My own experience is different from yours, I guess. I actually like >>> it when I post a patch, or suggest a concept, and Tom fires back with >>> a laundry list of reasons it won't work. >> >> This can be a problem with new submitters, though. If you're not used >> to the current community dialog, that email can be taken as "your idea >> is stupid because" rather than what it actually means, which is "fix >> these issues and resubmit, please". That's often not clearly >> communicated, and is important with new submitters. >> > > +1 to this as well. I definitely felt that way when submitting my > first patch. Robert might even recall a convo at a conference that he > and I had about it. If not for that I might have given up long ago. > Now I can say I am used to it though, and I appreciate the honest and > constructive criticism I receive because over time I have seen that > Tom and others are even critical of themselves and it's really for the > betterment of the final product.
For me our reluctance for any kind of change is a major demoralizing factor. For example, the recent discussion on Jeff Davis's patch on PD_ALL_VISIBLE flag. Our committers are quite candid in accepting that they may not have put in so much thought or did any real testing while adding the original code, but when it comes to making a change we show reluctance, ask for several test results and the patch author really needs to show extra worth for the change. That looks a bit unfair because the original code may not have received the same attention. Though I completely understand that the committers usually have a better sense and gut feel. If Heikki had not put that page level flag in the first place and if someone would have suggested adding that flag today, my sense is that we would have pushed him/her back and asked for many explanations like why waste a bit in the page or the performance increase is just 10% and that too in the worst case, so not worth it. Another example is the SKIP_PAGES_THRESHOLD in vacuumlazy.c. I'm quite convinced that the current default of 32 is quite arbitrary and the entire logic to not skip heap pages unless there are 32 in sequence is hard to justify, but if that needs to be changed, we would need hours of testing to show its worth. (BTW, I know both these changes are probably committed by Heikki. But thats just a coincidence :-) I've great respect for Heikki's talent and he is often right in his judgement) 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 ? I see a marked increase in the number of bugs reported (haven't really counted but just observation and it could be wrong). Not sure if its a result of increased testing/adaption or a slight drop in the quality or just because of the sheer increase in the number of features/changes we are doing. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers