Re: Project scheduling issues (was Re: Per tuple overhead,

Lamar Owen <lamar.owen@wgcr.org> writes:
> Historically we've concentrated our development efforts during beta to
> 'fixing beta problems only' -- but that model produces these
> extraordinarily long cycles, IMHO.  In the meantime people are
> literally chomping at the bit to do a new feature -- to the point that
> one developer got rather upset that his patch wasn't being looked at
> and 'stomped off' in a huff.  All because we were in beta-only mode.

There is a downside to changing away from that approach.  Bruce
mentioned it but didn't really give it the prominence I think it
deserves: beta mode encourages developers to work on testing, debugging,
and oh yes documenting.  Without that forced "non development" time,
some folks will just never get around to the mop-up stages of their
projects; they'll be off in new-feature-land all the time.  I won't name
names, but there are more than a couple around here ;-)

I think our develop mode/beta mode pattern has done a great deal to
contribute to the stability of our releases.  If we go over to the same
approach that everyone else uses, you can bet your last dollar that our
releases will be no better than everyone else's.  How many people here
run dot-zero releases of the Linux kernel, or gcc?  Anyone find them
trustworthy?  Anyone really eager to have to maintain old releases for
several years, because no sane DBA will touch the latest release?

I'm not trying to sound like Cassandra, but we've done very very well
with only limited resources over the past several years.  We should not
be too eager to mess with a proven-successful approach.
        regards, tom lane