Oleg Bartunov <o...@sai.msu.su> writes: > We would like to have your opinion what to do with these patches - leave them > for 8.5 or provide them to hackers to review for 8.4.
In theory 8.5, though you wouldn't be the first to start sneaking in late commits and given how long before the release I can't really think people would complain too much. Things have reached a perverse state. We've now been in a holding pattern for 4 1/2 months while development has basically ceased. Aside from committers, no contributors have been able to make any progress on any work for already that time and months remain before any reviewers will pay any attention to submissions. I have a bunch of ideas I wanted to follow up posix_fadvise with including posix_fallocate and more uses of posix_fadvise. I also wanted to return to the ordered merge-append which I still think is critical for partitioned table plans. I think it's clear that stretching feature freezes is a failed policy. Aside from delaying everyone else's work, it hasn't helped the projects we held the release for either. Those projects would have hit 8.5 in due course just fine but now surely we'll delay 8.5 based on the 8.4 release date. So they'll be delayed just like everyone else's work. I think in the future we should adopt a policy that only minor patches can be received after the first commitfest. Major patches are expected to submitted in the *first* commitfest and reworked based on feedback on subsequent commitfests. The last commitfest should be a real feature-freeze where only bug-fixes and minor changes are accepted, not major features. There seems to be a lot of resistance on the basis that there would be a long wait until features are seen in a release. Personally I'm only interested in when features get committed, not when they hit a release. But in any case I think experience shows that this would result in hitting the same release anyways and that release would be sooner as well. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers