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

From KaiGai Kohei
Subject Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)
Date
Msg-id 497D435A.6090005@ak.jp.nec.com
Whole thread Raw
In response to 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Kenneth Marshall
Date:
Subject: Re: [PATCHES] updated hash functions for postgresql v1
Next
From: KaiGai Kohei
Date:
Subject: Re: 8.4 release planning (was Re: [COMMITTERS] pgsql: Automatic view update rules)