From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgman(at)candle(dot)pha(dot)pa(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us, scrappy(at)postgresql(dot)org, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Development schedule |
Date: | 2005-02-26 18:47:19 |
Message-ID: | 4220C437.40200@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>YES! Yes yes yes! I try to plan my time, and the feature freeze data is very
>important in that planning.
>
>
This is also important for people considering sponsoring developers.
>Also, regardless of the issues Tom raised, 18 months is too long a release
>cycle, IMNSHO. If you do that and you take the time from feature freeze of
>release n to release date of release n+1, a developer could wait 2 years
>from the date of submission to see his/her feature in a release. 2 years is
>an eternity in this game. Just my $0.02 worth.
>
>
I think it depends on the level of features being worked on. Look
at how long there is between Oracle major releases or **GASP** Mysql?
I think it is silly to have to wait 18 months for a new release
of say plPgsql of plPerl, new functions or maybe a new group by
capability... This should be able to be in . releases.
However... PITR, Savepoints? Those are major coding efforts. It
makes sense that they would take that long.
Sincerely,
Joshua D. Drake
>cheers
>
>andrew
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
>
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment | Content-Type | Size |
---|---|---|
jd.vcf | text/x-vcard | 285 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2005-02-26 19:02:28 | Re: idea for concurrent seqscans |
Previous Message | Jim C. Nasby | 2005-02-26 16:16:27 | Re: idea for concurrent seqscans |