Oleg Bartunov <oleg@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!
