Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension - Mailing list pgsql-hackers

On Wed, May 27, 2015 at 9:24 AM, Stephen Frost <sfrost@snowman.net> wrote:
> I agree that the documentation needs improvement.  I don't agree with
> your assessment that the code quality is well below the level we
> normally expect, as committed.  That's clearly a difficult thing to
> judge, hence my compromise proposal to ensure that it either has a full
> review or gets reverted and not included in a released version.

That's not really acceptable in my view.  I looked at it shortly
before it was committed and said that it did not appear to me to be
close to being ready.  Noah took a look at it shortly after it was
committed and said that it did not appear to him to be close to being
ready.  Apparently, that's not good enough for you.  Your "compromise
proposal" is that a third committer other than yourself should go look
at it.

But that's not the way our community works.  It's hard to get one
extra committer to look at most patches, let alone three.  Committer
bandwidth is too precious for that.  Parallel sequential scan would be
in this release but for the fact that Andres wasn't confident in
certain portions of it, and I respected that by not committing even
though not a single other person backed up his concerns.

Basically, you're attempting to place the onus on other committers to
find the bugs in your patch.  If a third committer DOES come along and
review it, you'll fix whatever they find and say "well, now it doesn't
need to be reverted".  That's just not right.  As a committer, you are
responsible for getting it right the first time, not committing stuff
that is seriously broken and then cleaning it up as the issues are
reported, or when you have time.  If everyone adopted the approach
you're taking here, we'd have an order of magnitude more serious bugs
in a typical major release (and I would quit the project).

I note that there are already 11 followup commits fixing bugs in
pg_audit, including 7 in the first 24 hours.  It's usually not a good
thing when you can get the regression tests for a piece of
platform-independent code to pass in less than 8 tries.  I suspect,
but do not know for certain, that this is just the tip of the iceberg.

> I find it confusing that there is no appreciation here for the level of
> interest and excitment which has happened around these features, or how
> having these capabilities will grow our community, or how working with
> David and others to develop new PostgreSQL developers who may some day
> become committers and continue to carry PostgreSQL forward long past
> when we are gone is a worthwhile goal.

Those things are true of many patches.  They don't excuse committing
poor code or stream-rolling community process.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company