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, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers