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

On 22/01/13 22:35, Dimitri Fontaine wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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.
> +1
>
> I still think it takes loads of stupid ideas and discussion before
> reaching a point where a patch can be brewed and proposed. Once you
> reach a certain point though, typically when we begin talking about
> careful implementation details, then my feeling is that a patch is
> necessary for the discussion to remain a productive use of everyone's
> time.
>
> So the goal in your proposed terms would be to only spend time cooking a
> patch for about 10% of your ideas, and be prepared to rewrite it from
> about scratch a least a couple of times (for a simple enough patch).
>
> That matches my experience.
>
>> 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 ...
> I share that feeling that while commit fest is a giant step forward as
> far as allowing patches to make progress and hit the next release
> without delaying said release, it might be encouraging people to cook
> patches too early: there's no entry for "crazy ideas" or design.
>
> I guess in getting more formal it's harder for newcomers to just throw
> (not so) random ideas on list, as it used to be the only way to begin a
> contribution to PostgreSQL.
>
> My understanding is that we already have too many lists, but maybe we
> could have another one to just speak about those 10% ideas that turn
> into patches or commit fest entries (pgsql-workers) and keep hackers for
> crazy idea, design, community processes, etc. I'm not sold on it myself,
> but it could maybe help in encouraging design ideas again?
>
> Regards,
Maybe we should have a list named 'crazy talk' for such ideas.

Possibly encourage Tom and other pg heavy weights to write brief notes
about their intentions. So people can see that even the best pg
developers can have half baked ideas, to encourage newcomers and less
experienced developers to let people know well in advance what their
intentions are.

Most people don't realize tat to be really stupid, one needs to be both
highly intelligent and creative!

More to the point, perhaps, is that the most effective developers often
have many silly ideas that are: well intentioned but not practicable,
initially implemented poorly,or develop something that seem good until
grim reality hits. However, when they strike gold, they improve pg: in
considerable ways, make trivial changes that are disproportionately
useful,or put a lot of effort into making what superficially looks like
a simple idea to actually work without bad side effects.

I am sure with even my 40+ years of development experience in other
areas, that if I attempted a 'trivial' change to pg, that I would most
likely cause unwanted side effects without realizing it - assuming I got
it working at all! Tom and others would then quite rightly reject my
patch, or give me constructive criticism (that I might take as negative
feedback if I was depressed!). Howevever, if I first proposed my idea on
a 'crazy talk' mailing list, then possibly I would either get
suggestions as to how to proceed to avoid such side effects, or be told
that what I proposed was not worth the effort. In the latter case, it
would be up to me to research reasons for proceeding, if I felt strongly
that I was right.

Cheers,
Gavin