Re: CF3+4 (was Re: Parallel query execution) - Mailing list pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.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,