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.

+1. Shorter release cycles are maybe good for fancy GUI oriented
applications, but not so good for DBMS.
--
Tatsuo Ishii
SRA OSS, Inc. Japan