On Tue, Jan 22, 2013 at 11:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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.
That reminds of my conversation with our masters thesis guide who is a accomplished professor and an IEEE fellow with loads of research work to his credit. I was disappointed that I'm not doing a *significant* research work, to which he replied that 90% work is just like that. But every once in a while someone gets inspired by that work and either take that further or creates a landmark work out of it. I was satisfied with his answer. So the 90% crap you mentioned is probably not all that crap and we need that so that newer ideas are conceived while discussing some of them. > 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. > Yeah, probably that expectation needs to be set. What will help more is to somehow guide the patch submitter to a related area and encourage to handle that issue or the same issue in a little different but more acceptable way. I think we already do a lot of that but more can be done. Its OK to push back patch submitter and they will be fine as long as their second or third attempt succeeds. If Tom or equivalent feels that the idea is no starter, just reject it at the first go and before the submitter has done multiple iterations to save everyone's time and reduce frustration. > 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, Agree. Many a times its important though that senior folks give their opinion one way or the other, early in the review cycle. That does not happen always. I remember during HOT development I used to wait for days and weeks for Tom to take note of my emails and respond, even if he is ripping apart my ideas. But the fact that HE has looked into the work was a great satisfaction. Once someone is taking interest then there is a chance of convincing that person. Thankfully we have a lot more Tom-alike (not Tom yet :-)) now than 5 years back and thats why we are seeing a lot more intrusive work. > There was some discussion at the last dev meeting of > creating a "design review" process within commitfests, but nothing got > done about it ... > Yeah, agree. May be we need to put that in the process itself. So no patch be submitted unless the idea has been discussed and agreed upon to some extent. Of course, few things you will only know once you start writing the code. But at least the major points must have been accepted by at least one major developer or a committer. 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
