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

> 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.
>
> 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?).

As much as I hate to say it, I agree with all of this. I think it
would be a good to see whether some subset of the Hot Standby can be
committed - perhaps the "infrastructure changes for recovery" portion.
With respect to the remaining patches, I think that anything that is
basically committable now should be committed and everything else
should be considered returned with feedback (or reverted, in the case
of updatable views). Nearly every patch that is still on the
CommitFest wiki has undergone significant changes since the CommitFest
started, and I don't think it's the purpose of CommitFest to give
people another 3 months to work the bugs out of a patch that basically
isn't finished, or to have the committers finish them in lieu of the
original submitters. And if it's really true that we will be in
feature freeze for 10 months (11/1/08-9/1/09) then I don't think
that's remotely a good idea.

I would, however, like to see us make a commitment to actually review
SE-PostgreSQL. There was some talk that we might not want to include
this feature in core at all, and if that is the case then I think it
is long past time to make that decision. Assuming that isn't the
case, then we need to get past the stage where we make occasional
comments on the overall architecture and get down to really reading
the code. I am willing to help with this but I don't have either the
time or the qualifications to do it single-handedly. To be brutally
honest, I don't care about the feature at all: the only thing I ever
do with SELinux is turn it off (row-level DAC is mildly interesting to
me). But I think that if we want to build a community of developers
around PostgreSQL, we'd better at least look at the work they submit.

...Robert