David E. Wheeler wrote:
On Mar 16, 2009, at 1:41 PM, Tom Lane wrote:
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
I think that if you can strictly time-limit the final CommitFest in the
same way that you time-limit the others, then whatever doesn't get in
that last one will be deferred to the first fest for the next major
version.
The earlier commitfests were not time-limited either. They lasted until
all the patches were dealt with; either committed or bumped to next
commit fest. It's just that when you know there still at least one more
commitfest a couple of months ahead, everyone feels more happy to bump a
patch and to have one's patch bumped to the next one. In the last one,
it's a lot harder to do that because that means bumping to the next
release, and you don't even know when the next commitfest is.
The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release,
and beta would start right after the first commit fest, a week or two
after the submission deadline. We failed to enforce that. In the next
release cycle, I think we need to be more explicit about that policy
throughout the release cycle and really enforce it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
