Re: Heroku early upgrade is raising serious questions
| От | Greg Sabino Mullane |
|---|---|
| Тема | Re: Heroku early upgrade is raising serious questions |
| Дата | |
| Msg-id | edc98120d09c1fd24fb9c979c8745cd2@biglumber.com обсуждение исходный текст |
| Ответ на | Re: Heroku early upgrade is raising serious questions (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: Heroku early upgrade is raising serious
questions
Re: Heroku early upgrade is raising serious questions |
| Список | pgsql-advocacy |
-----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-----
В списке pgsql-advocacy по дате отправления: