> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate