Greg,
>> [There were complaints upthread about things like how Aster's patch
>> submissions were treated. Those were WIP patches that half implemented
>> some useful ideas.
There are two reasons why I think we failed with the Aster patches:
1) I passed Aster along to Bruce, who said he would review the patches
and give them a private response on them before they put them on
-hackers (which response would be "these aren't nearly ready") Bruce
punted on this instead, passing their submissions straight through to
-hackers without review.
2) Our process for reviewing and approving patches, and what criteria
such patches are required to meet, is *very* opaque to a first-time
submitter (as in no documentation the submitter knows about), and does
not become clearer as they go through the process. Aster, for example,
was completely unable to tell the difference between hackers who were
giving them legit feedback, and random list members who were
bikeshedding. As a result, they were never able to derive a concrete
list of "these are the things we need to fix to make the patch
acceptable," and gave up.
While the first was specific to the Aster submissions, I've seen the
second problem with lots of first-time submissions to this list. Our
feedback to submitters of big patches requires a lot of comprehension of
project personalities and politics to make any sense of. As I don't
think we can change this, I think the best answer is to tell people
"Don't submit a big patch to PostgreSQL until you've done a few small
patches first. You'll regret it".
>> That goes double for some of the people complaining in this thread about
>> dissatisfaction with the current process.
The problem is not the process itself, but that there is little
documentation of that process, and that much of that documentation does
not match the defacto process. Obviously, the onus is on me as much as
anyone else to fix this.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
