> 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
