Re: CF3+4 (was Re: Parallel query execution)

On Tue, Jan 22, 2013 at 11:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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