On Tue, May 10, 2011 at 3:09 PM, Greg Stark <gsstark@mit.edu> wrote:
> The thing is, I think things are much better now than they were three
> or four years ago. At the time the project had grown much faster than
> the existing stable of developers and the rate at which patches were
> being submitted was much greater than they could review.
Just in the last 2.5 years since I've been around, there have, AFAICT,
been major improvements both in the timeliness and quality of the
feedback we provide, and the quality of the patches we receive. When
I first started reviewing, it was very common to blow through the
CommitFest application and bounce half the patches back for failure to
apply, failure to pass the regression tests, or other blindingly
obvious breakage. That's gone down almost to nothing. It's also
become much more common for patches to include adequate documentation
and regression tests - or at least *an effort* at documentation and
regression tests - than was formerly the case. We still bounce things
for those reasons from time to time - generally from recurring
contributors who think for some reason that it's someone else's job to
worry about cleaning up their patch - but it's less common than it
used to be.
We still have some rough edges around the incorporation of large
patches. But it could be so much worse. We committed something like
six major features in a month: collations, sync rep, SSI, SQL/MED,
extensions, writeable CTEs, and a major overhaul of PL/python. While
that's likely to delay the release a bit (and already has), and has
already produced quite a few bug reports and will produce many more
before we're done, it's still an impressive accomplishment. I'm not
sure we could have done that even a year ago.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
