Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)
Date: 2009-01-26 05:00:10
Message-ID: 497D435A.6090005@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> and I'm beginning to think that we need to invoke that provision.
> Particularly with regard to hot standby, which by any sane reading was
> not close to being committable on 1 November (a fortiori from the fact
> that it's *still* not committable despite large amounts of later work).
> I'm also feeling that we are not in a position to commit SE-Postgres in
> a timely fashion; which is not KaiGai-san's fault, rather that of the
> community which has taken nearly zero interest in that patch.

Yes, few feedbacks have been a concern for me, though I can understand
that reviewers/commiters had to deal with various kind of many patches
for the v8.4 development cycle. (Needless to say, I remember Tom commented
a lot on CommitFest:May and it made SE-PostgreSQL well.)
If SE-PostgreSQL is not still committable phase, I want to discuss what
code should be reworked and what items are remained.
Because it was unclear, I had to review patches by myself in this January. :(

In addition, I would like to mention about the scale of patches.
| % diffstat sepostgresql-sepgsql-8.4devel-3-r1467.patch
says,
| 110 files changed, 9813 insertions(+), 16 deletions(-), 924 modifications(!)
However, the total number of insertions under "src/backend/security" and
"src/include/security" is 8207 lines of 9813. It modifies 924 lines, but
504 lines of 924 is due to a new field of pg_attribute system catalog.
Please note that it never applies massive rough-mannered fixes all over
the core implementation, so it is informidable.

> If we want to ensure that 8.5 development opens soon, what we have to do
> is reject those two patches, revert updatable views, and finish up the
> other stuff (which is all small and could likely be dealt with in a week
> or two). That puts us in position to go beta by perhaps mid-February
> with release perhaps on May 1. If we don't, I hereby predict that 8.4
> release will not happen before September. Trying to deal with those
> late, large features will add *at least* one more month to commitfest
> and *at least* one more month to beta (you think they'll be bug-free?).

I can understand we cannot postpone to release v8.4 forever and it is
important to see a calendar. However, I would like folks to see not
only a calendar, but a current *trend* also.

Nowaday, we have no days without looking a term such as SaaS/PaaS or
cloud-computing. It consists of various kind of web applications and
highly-integrated database system on cluster systems.
In this movement, end-users pay their attention on "availability" and
"security" most. If we can include these features in a timely fashion,
it makes PostgreSQL more attractive compared to other DBMSs.
Needless to say, I'll pay my maximum effort to reduce the additional
days, even if it is estimated one more month is necessary.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2009-01-26 05:14:22 Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)
Previous Message Kenneth Marshall 2009-01-26 04:27:03 Re: [PATCHES] updated hash functions for postgresql v1