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

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,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support