Re: Heroku early upgrade is raising serious questions - Mailing list pgsql-advocacy

On Wed, Apr 03, 2013 at 06:14:25AM -0400, Dave Page wrote:
> 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 do agree on the confidentiality problem, I do not agree in the "in most cases could easily be using the
community packages" part. Honestly, why would anyone pay a support company to
build packages if they can use the free community ones instead? Ok, maybe some
do because they simple don't know, but in general itÄs because they have some
special needs.

> 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.

So then it's a matter of users? What is the number of user one has to have to
qualify? How do we count users? Installations, db admins, real database users
as in customers? As a support company (bad wording actually as support doesn't
mean you're creating packages) serving a customers with thousands of instances,
do I qualify?

Don't get me wrong, I'm not complaining and I don't have a ready made solution
for this, but I do strongly believe we should come up with a set of rules, that
are discussed and decided upon in the open. We definitely don't want this to
look like a (strange?) decision made behind closed doors, or do we?

> Let me state this very clearly:
>
> *** Heroku have done nothing wrong ***

That much I learned so far, sorry for accusing Heroku. It seems that press
report wasn't theirs and they received permission to start deploying early.
Although again I wonder why all this decision making hasn't been open. Why are
their customers more important than ours or EDB's or any other company that
hasn't rolled out the patches yet.

> I cannot go into details at the moment, but their actions have been

Why? I can see a reason why we don't talk about the bug or the fix in the open.
Sure that makes sense because we have to have the fixed version out first. But
why does the same hold for communication about deployment embargo?

> taken following talks with the core team, in a difficult time, with no
> precedence within the community to follow and very little time for

You mean the PostgreSQL community, right? We're not the first project that
discovers a nasty security hole. And we won't be the last.

> in-depth discussion. We have had similar discussions with other large
> DBaaS providers, who have different architectures with different
> implications to consider.

Sure and those details don't belong into the open.

> 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).

Yes, hindsight is always 20/20. Again, I hope you see my email is part of a
constructive discussion to get to a better policy for the next time, that
hopefully will never come. :)

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL