Re: small but useful patches for text search

Robert Haas wrote:
> > Well, we have been working on stuff for the past month so it was not
> > like we were waiting on SE-PG to move forward.
>
> Stuff related to the CommitFest?
>
> AFAICS, the only committer who has done any significant review or
> committing of patches in the last month is Heikki, who extensively
> reworked and then committed infrastructure changes for recovery on
> February 18th (2 days shy of a month ago) and then extensively
> reviewed Hot Standby and SE-PostgreSQL. It's really, really good that
> those patches have finally received some extensive review, both
> because now some version of each of them will likely make it into 8.5,
> and because now we have only a handful of patches left that Tom has
> said are pretty close to being committable. But I don't see how you
> can say it didn't delay the release.

You are assuming that only commit-fest work is required to get us to
beta. You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty left.

Tom has done work fixing optimizer bugs introduced in 8.4. I have had
EnterpriseDB work to do and am working on the release notes now. The
bottom line is that there is lots of cleanup required to get to beta
independent of the last commit fest work.

> Frankly, if we'd rejected on January 1st all of the patches that (1)
> were submitted on time, (2) had been reviewed in a timely fashion, and
> (3) had not been resubmitted in largely committable form, we would
> have bounced infrastructure changes for recovery, hot standby,
> column-level privileges, autovacuum and reloptions, and probably
> parallel restore. If the committers who subsequently worked to get
> those changes into the tree had devoted an equal amount of effort to
> what would have been left in the commitfest after so doing, we would
> long since be done with this commitfest and into beta. But committers
> are free to spend their time on the projects they think are most
> interesting or which their employer is willing to pay them to work on,
> so that didn't happen.

I agree if we had said "no" to those patches we could be farther now,
but I am not sure how much farther.

> This is kind of understandable from the point of view of the
> committers, and it's even sorta good for the project as a whole to the
> extent that it prioritizes more interesting features over less
> interesting ones, but it's pretty frustrating for non-committer
> contributors. Any non-committer who pushes for a hard limit on the
> length of the commitfest is taking the risk that next time the patch
> that none of the committers are interested in will be theirs. So
> nobody really wants to argue for that. But the alternative is to
> argue that the commitfest should continue until all the patches have
> gotten some reasonable minimum amount of review, and that means the
> commitfest can continue for a very, very long time during which
> non-committers can't expect to get any new patches looked at. That's
> not very appealing either. The commitfest process really only works
> if the committers review all of the patches submitted within some
> reasonable period of time - if that isn't possible, there really isn't
> going to be a satisfactory solution.

Again, this assumes the commit-fest is the only old on beta starting.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +