On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> 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.
I mostly agree with this, but there is one fly in the ointment: if a
patch really hasn't been seriously looked at by a committer, bumping
it recreates one of the problems CommitFests were designed to avoid -
patch limbo. I feel pretty good about the decisions to postpone Hot
Standby and SE-PostgreSQL (not that my personal opinion necessarily
counts for much, but that's how I feel); I would have felt less good
about it if the same decision had been made a month ago. But on the
other hand that means 8.4 will be a month later. If we could have
gone through the same process two months earlier, or if we could have
released 8.4beta and done those reviews on the side during the beta
period, that would have been best of all.
I basically agree with the idea of time-based releases, but if the
committers cherry-pick the patches that are easily dealt with and
never touch the more complex ones, it leads to a different set of
problems... I'm not sure what can be done about that, though.
...Robert
