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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
