Re: commit fests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: commit fests
Date
Msg-id 15483.1264283839@sss.pgh.pa.us
Whole thread Raw
In response to Re: commit fests  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: commit fests  (Dimitri Fontaine <dfontaine@hi-media.com>)
Re: commit fests  (Robert Haas <robertmhaas@gmail.com>)
Re: commit fests  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Goal being to continue being responsive to authors in a way that will
> not compromise our stability, but if that means *all* qualified talents
> of the community get assigned to release management team… I stop seeing
> the point.

There seems to be some weird notion abroad in this thread that the
primary time sink during beta is unspecified low-skill "release
management" tasks.  There really isn't all that much of that.

What I find takes up a lot of time is post-commit patch review, fixing
reported bugs, and documentation cleanup.  Now we could doubtless find
other people to do the purely copy-editing aspects of doc cleanup, like
fixing less-than-stellar English, but what I'm really looking for is
factually incorrect or obsolete statements.  It takes someone who's
pretty much familiar top-to-bottom with the whole product to do a decent
job of spotting things that were true awhile ago but aren't any longer.
We just don't have many people who (a) can and (b) will do that work.

What I think we really need for beta, and could reasonably hope to get,
is a larger and better-organized beta testing effort.  But we are not
going to get that if people are thinking about new development and
commit fests instead of testing what's already there.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
Next
From: Magnus Hagander
Date:
Subject: Re: 8.5 vs. 9.0, Postgres vs. PostgreSQL