On Wed, Apr 3, 2013 at 5:31 AM, Michael Meskes <meskes@postgresql.org> wrote:
> On Wed, Apr 03, 2013 at 05:06:08AM -0400, Dave Page wrote:
>> PostgreSQL support companies do not generally produce PostgreSQL
>> binary packages that are available for anyone to use (for a service
>> fee or otherwise) either via download or on a platform like a cloud
>> service. There are a handful of exceptions to that rule (EDB for
>> example, as we produce the installers), but most, if not all of those
>> companies are on the packagers list already.
>
> So that means if said support company creates packages for its customers it
> should be on the packagers list? After all anyone could get the packages from
> that company, couldn't they? Is there a any description as to who is eligible
> for the packages list?
First; I'm giving about my personal opinion at the moment, not
representing -core.
I do not believe that regular support companies should be included,
because there are too many of them, and they will likely be packaging
for a very small audience who in most cases could easily be using the
community packages. With so many people on the list, security and
confidentiality becomes impossible to enforce.
I support having the packagers of the mainstream packages on the list,
e.g. installers, RPMs, DEBs, Postgres.app, OS vendor packages etc
(e.g. Palle who provides the FreeBSD ports) etc.
I also support having the large scale DBaaS providers on the list, as
they provide Postgres instances for thousands of users, very publicly
- Heroku, as the obvious example, have hundreds of thousands of
databases on their platform.
> And of course I take it there is a code of conduct for
> this list, albeit Heroku didn't honor that one.
Let me state this very clearly:
*** Heroku have done nothing wrong ***
I cannot go into details at the moment, but their actions have been
taken following talks with the core team, in a difficult time, with no
precedence within the community to follow and very little time for
in-depth discussion. We have had similar discussions with other large
DBaaS providers, who have different architectures with different
implications to consider.
In hindsight, I'm sure the rest of core will agree we might have
handled this better in some respects, but as we all know, hindsight is
a wonderful thing. We will be working on policies to guide us in the
future in the event that something similar happens again (and as
you've probably seen, that's already started).
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
