-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Stephen Frost replied:
> Who gets added and who doesn't would be the committee's responsibility.
> Risk and exposure would weigh into that decision. DBaaS providers had a
> much higher from this most recent bug than even very large scale
> internal deployments. When asking "do we add them all?", the answer
> will have to be 'no' or there would end up being little point.
Still sounds like a huge mess. Who gets put on the committee? Wouldn't the
committee need to have a huge database of potential people to notify, including
details of their systems (e.g. do they use tsearch, if this is a tsearch bug).
Would they be deciding on people on a case by case basis, or just deciding
on what class of people get notified. If the latter, why not just have
core continue to do it? If the former, how can that be agile enough for a
quick turnaround? Would companies have to be requested to be added to
this database, in the hopes they get notified of a serious bug before it
is released?
Perhaps we can just agree that the way this was handled was a mistake, and
strive for more transparency and egalitarianism next time? Sure, Heroku has
a huge list of servers listening on 5432, but do did that place in Poland,
and apparently they did not get a early warning.
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201304112203
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAlFna3IACgkQvJuQZxSWSsi3FQCdHjlrxnS+izZTay7dd2eVvk/l
mQEAoIda6OkcpbZ9Y59nubSg0faVzUO3
=PSSA
-----END PGP SIGNATURE-----
