​So, Noah's excellent response has been ignored (from what my threaded
Gmail view tells me) at this point...​

On Tue, Feb 2, 2016 at 6:25 PM, Curtis Ruck <
curtis.ruck+pgsql.hack...@gmail.com> wrote:

> Robert,
> This isn't wrong.  I don't see anyone else trying to submit anything in
> reference to auditing.  Just because there have been multiple
> implementations in the past, based on commit histories, there have only
> been a few that tried getting into core or contrib (that i can find in
> mailing list history).

​And so if pgaudit is such an improvement then by this logic a poor
implementation would have been committed in the past just because someone
wrote something and proposed it for commit.​  Noah summarized his quite
weighty point-of-view on the outcome of the patch that has been put forth.
One dynamic of which is whether it would be easier - and overall more
productive - to make installing auditing as an extension easier compared to
getting it into core.

> I think if there was a valid commit path laid out for getting auditing
> into core, or into contrib at least, most users would probably find that
> sufficient.  But it seems that every time someone tries to incorporate
> auditing, there are countless and varied reasons to deny its inclusion.

​You pre-suppose that people are willing and able to spend their time
trying to predict the future when in reality they would rather be convinced
that what has been put in front of them is worth committing.  For what I
presume are myriad of both technical and political reasons the people who
have the final say have not been so convinced.

> It just seems after reading the mailing list history, that there is a lack
> of interest by people with commit authority, even though there is a decent
> interest in it from the community, and honestly, no one really likes
> auditing, but its one of those damned if you do (in performance) and damned
> if you don't (in legal) things.

​So either through persuasion or compensation you need to increase

> Additionally Robert, given your professional status, you are by no means
> an unbiased contributor in this discussion.  Your stance on this matter
> shows that you don't necessarily want the open source solution to succeed
> in the commercial/compliance required space.  Instead of arguing blankly
> against inclusion can you at least provide actionable based feedback that
> if met would allow patches of this magnitude in?

​Even if that were to be true that would not prevent others involved from
moving things forward - an objection like "I don't want this in -core
because it will eat into my employer's profits" won't persuade many
people.  Nit-picking patches might get a bit further but if there is
sufficient buy-in from the community as a whole it won't last long.​  So
maybe Robert doesn't actively help as much as he could but a lack of
helping is not the same as hindering.

> I'm personally fine with fiscally rewarding organizations that assist my
> customer in succeeding, but its hard to convince my customer to fund open
> source, even though they wouldn't be able to do 75% of what they do without
> it.  Based on past experience this is the same most open source
> organizations face, especially when they don't have the marketing engine
> that the large commercial players have.

​Which is why the model seems to be for the service provides who leverage
PostgreSQL to charge their customers enough so that part of the profit can
flow back into the community that they have based their livelihood upon.
Otherwise, maybe features such as this should end up in commercial
offerings and those customers who won't charitably contribute will instead
have an easier time seeing that at least they are spending less for
PostgreSQL licensing than they would for similar features in competitors

​In my estimation this ​whole thread started poorly and thus likely will
not garner much if any forward progress on the issue.  Noah's response was
spot-on despite that fact and a proper response to it would likely move
things forward in a more positive manner.  A separate thread could be
started to discuss what can be done to improve the scenario where excellent
patches and/or extensions are available but are not in core.  These two
dynamics are separate and trying to hit both in one thread is just going to
dilute things so that likely neither topic gets progressed.

David J.

Reply via email to