Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension

On Tue, May 26, 2015 at 8:10 PM, Stephen Frost <sfrost@snowman.net> wrote:
> I certainly welcome review from others and if there is not another
> committer-level formal review before we get close on 9.5 (say, end of
> August), then I'll revert it.  There is certainly no concern that doing
> so would be difficult to do, as it is entirely self-contained.

Like Noah, I'm unhappy that this patch went in.  I stated a few days
before it was committed that I felt the code quality and documentation
were well below the level we normally expect.  Your response was to do
a little more work on the patch and then commit it without so much as
reposting it.  Clearly, we have completely different ideas about what
constitutes an appropriate response to the sort of comments I sent.

A near-record number of committers have objected to this patch in all
kinds of different ways.  There have been concerns about process,
concerns about code quality, and concerns about whether this is really
something that we want.  The normal way that works is that you either
(a) revise the patch or (b) try to convince the person raising the
concern that it's OK.  The concern is addressed when the person who
raised it says it is, and not just because you thought about it and
decided it was OK.  This can be taken too far in the other direction,
but we're not close to that in this instance.

I am particularly troubled by the fact that what has happened with
this patch is very much like what happened with row-level security: a
patch that clearly wasn't finished and clearly had not had adequate
review got abruptly committed - by you - without any consensus so to
do.  It seems likely to me that by now row-level security has had
enough review that it is solid enough to be in the tree - in
particular, I am encouraged by Dean Rasheed's work to improve the
patch.  However, it is absolutely not the community process for that
stuff to happen after the code is already in the tree.  It is the
community process for that stuff to happen before the code is in the
tree.

It will be impossible for our community to continue delivering quality
software if you persist in taking this approach.  Either the other
committers will have to spend an inordinate effort fixing (or
convincing you to fix) the stuff you break - instead of working on our
own projects - and other people's patches - or we will have to ignore
your commits, and the things that are broken in those commits will
become bugs in our releases.  Either way, the community loses.

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