On 22/01/13 22:35, Dimitri Fontaine wrote:
Tom Lane <t...@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,
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
