Re: [CORE] Restore-reliability mode
От | Tom Lane |
---|---|
Тема | Re: [CORE] Restore-reliability mode |
Дата | |
Msg-id | 26673.1433514236@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [CORE] Restore-reliability mode (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [CORE] Restore-reliability mode
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Jun 5, 2015 at 2:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> Agreed. Cleanup can occur while we release code for public testing. > The code is available for public testing right now. Only to people who have the time and ability to pull the code from git and build from source. I don't know exactly what fraction of interested testers that excludes, but I bet it's significant. The point of producing packages would be to remove that barrier to testing. > Stamping it a > beta implies that we think it's something fairly stable that we'd be > pretty happy to release if things go well, which is a higher bar to > clear. So let's call it an alpha, or some other way of setting expectations appropriately. But I think it's silly to maintain that the code is not in a state where end-user testing is useful. They just have to understand that they can't trust it with production data. > I can't help noticing for all the drumbeat of "let's release 9.5 beta > now", activity to clean up the items on this list seems quite > sluggish: > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items While we need to work on those items, I do not agree that getting that list to empty has to happen before we release a test version. I think serializing effort in that way is simply bad project management. And it's not how we've operated in the past either: getting the open items list to empty has always been understood as a prerequisite to RC versions, not to betas. To get to specifics instead of generalities: exactly which of the current open items do you think is so bad that it precludes user testing? I do not see a beta-blocker in the lot. regards, tom lane
В списке pgsql-hackers по дате отправления: