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
