> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
