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

On Monday 10 June 2002 04:11 pm, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > Historically we've concentrated our development efforts during beta to
> > 'fixing beta problems only'

> There is a downside to changing away from that approach.

There are downsides to every approach. The question is 'Which set of
downsides are we most comfortable with?'

> 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 ;-)

Well, this is the one downside the Marc's proposal. It boils down to
self-discipline, though. Unfortunately not everyone is as disciplined as you
seem to be in the area, Tom. I certainly cannot claim a great deal of
self-discipline. BTW, that is meant as a compliment to you, Tom.

> 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.

I'll have to agree here -- but I also must remind people that our 'dot zero'
releases are typically solid, but our 'dot one' releases have not been so
solid. So I wouldn't be too confident in our existing model.

And I'm not so sure the model is the producer of our sterling record
heretofore. I'm more of the mindset that the quality and discipline of the
developers is the real reason.

> 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?

We already have some of that problem due to the difficulty in upgrading.
People wait and see if the features warrant the downtime and pain of
upgrading. Meantime they live with security holes and bugs in our own
unmaintained older releases. And dump and restore upgrades are not painless.
I will admit that I've not used pg_upgrade in some time -- I understand
moving from 7.1 to 7.2 is much less painful using pg_upgrade. However,
pg_upgrade was released in contrib as being a 'handle with great care'
utility that no sane DBA is going to touch.... Catch 22.

So, I don't necessarily agree that we should hold up our development model as
the panacea, and I'm not thoroughly convinced that the quality of our
releases is related directly to the development model. I believe it is
directly related to the caliber of the developers.

That said, good developers can produce good quality regardless of the model
used if they will discipline themselves accordingly.

> 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.

Interesting reference....

Why not try this one cycle and see what happens? No one is going to force
anyone else to develop new features when they want to fix bugs.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11