Re: Feature Freeze date for 8.4

On Mon, 22 Oct 2007, Tom Lane wrote:

> If we want a short FF-to-beta period then the criterion will have to be 
> that patches are either committed or darn near ready to commit on the FF 
> date.

I think you're stuck with a certain amount of schedule delay regardless of 
how mature code is at submission time when there's a large performance 
component involved, rather than strictly a feature one.  There was a lot 
of that in 8.3, where it seemed to me the benchmarking and similar 
quantifying of the true impact of the patch wasn't correlated so much with 
the code quality at submission time.  Good performance testing of any sort 
takes a long time, there's only so many people who can do it, and having a 
couple of different perspectives is almost mandatory to avoid optimizing 
only for a particular application type.  When you have a couple of such 
things in the pool, you're not going to get a lot of work done on multiple 
patches of that type in parallel, especially when there's any overlap 
between them.

I personally think that shorting the minor release cycle time too far is 
counterproductive anyway.  From the DBA and system administrator 
perspective, new version releases are a giant QA and maintenance mess. 
Better to have less of them that each add larger features rather than a 
more regular stream of small ones from where I'm sitting.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD