Re: Project scheduling issues (was Re: Per tuple overhead, - Mailing list pgsql-hackers

On Monday 10 June 2002 04:11 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.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