Re: PostgreSQL Auditing
| От | David G. Johnston |
|---|---|
| Тема | Re: PostgreSQL Auditing |
| Дата | |
| Msg-id | CAKFQuwZLDyHzmLnzr6Shez7BSbxU7te+jhLjzEMAPDKntLbMng@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PostgreSQL Auditing (Curtis Ruck <curtis.ruck+pgsql.hackers@gmail.com>) |
| Список | pgsql-hackers |
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.hackers@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 interest...
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 offerings.
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.
В списке pgsql-hackers по дате отправления: