Re: beta to release - Mailing list pgsql-hackers

On Fri, May 7, 2010 at 11:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I would say the expectation for individual developers is "test, and
> read code".  It's certainly not time to be starting new feature
> development yet.

I am humbly of the opinion that the expectation you have enclosed in
quotation marks is far too general to allow me to contribute anything
useful.  If you, or whoever is driving this release process (if indeed
it's being driven and not just meandering rudderless), would care to
outline something more specific that you feel it would be useful to
have me test, look at, or attempt to address, then I will devote some
of my time to doing that.  But I won't volunteer to go reread the
entire code base or test things at random in the hopes of finding a
bug.  I don't believe that most other developers are doing that,
either.  What I think they are doing is lying low and developing their
patches without the benefit of feedback from the list so as to avoid
getting yelled at for writing them during beta, or else doing
non-PostgreSQL work until beta is over.  For small patches, that
probably doesn't matter very much: those can be developed just as well
later on as they can now.  For large patches, it's evil incarnate:
people who don't start working on those patches (or don't get any
useful feedback on them) for another 3 months will be at least 3
months later in finishing them (maybe more, depending on their summer
vacation schedule and just when their boss will let them put time into
it), and that means they'll be done right at the end of next release
cycle.  From a project management perspective, I think we will be FAR
better off if we take the time to respond to design proposals early
and often.  I agree we don't have time to do detailed code review now,
but telling people not to write any code or ask any questions at this
stage of the process is not going to result in them spending more time
on beta; it's going to result in them spending less time on
PostgreSQL.

In further support of the above, let's consider the three largest
patches that were outstanding at the end of the 8.4 release cycle.  I
believe these to be (1) Hot Standby, (2) Streaming Replication, and
(3) SE-PostgreSQL.  How much work got done on those patches between
the end of the last CommitFest for 8.4 and the beginning of the first
CommitFest for 8.5?  If you go back and look at the archives, I
believe you will find that the answer is "virtually none".  SR and
SEPG were submitted *virtually unchanged* from the versions that
existed at the end of 8.4 and were both summarily bounced out of the
2009-07 CommitFest for exactly that reason.  Hot Standby wasn't even
submitted to that CommitFest.  There could be many reasons for this
and correlation does not imply causality, but wouldn't it have been
nice at least SOME of the development that happened between July and
November (by which time the bulk of the development was done) had
instead happened between February and July?  I sure think so.  I think
we'd be a whole lot happier about this release right now if we'd
committed HS and SR in September rather than November and January, and
while we can speculate all day about whether that would have happened
under any circumstances, our process rendered it a virtual
impossibility.

> As for tracking, historically Bruce has maintained a list of open
> items, but I think we ought to move that over to a wiki page.
> The existing PostgreSQL_9.0_Open_Items page would serve fine.

+1.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company