Magnus Hagander wrote:
On Wed, Oct 10, 2007 at 11:50:12AM +0300, Marko Kreen wrote:
On 10/10/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann <[EMAIL PROTECTED]> wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go through the formal
review
process.
I have no opinion as to the patch itself (other than the fact that
it's a not bug fix), but I think this patch should be reverted
because it's (a) after feature freeze, (b) had no discussion on
hackers (or patches), (c) is not a bug fix. IMO rules can be bent
but there should always at least be discussion before a new feature
is committed after feature freeze and definitely after beta.
Otherwise, the rule appears to be if you can get it in somehow, it's
in.
I think this almost says it all. My particular gripe about this whole
thing is that there are other features that are not too intrusive (or
appear so anyway) that are easily more useful that are not being
considered at all. Namely,
http://archives.postgresql.org/pgsql-patches/2007-10/msg00087.php . It
makes the whole process seem tilted and subjective.
IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
Yes, reverting is an option, but please, do that at least with
an understanding what actually happened. Current discussion
seems to give picture that Jan committed some private piece of
code without consulting anybody which was not the case.
At least I am fully aware that it's not a private piece of code. And in
general, I trust Jan (and of course Tom as well) to take a patch from
elsewhere and put it in.
My objections are twofold:
1) We don't add things after beta. I can live with adding it during feature
freeze since it's contrib, and reviewed by these people, but I think it's
horrible to do it after we've shipped beta1.
yeah that is exactly the point - if we do have a feature freeze we
should hold to it. if we are in BETA we should not add any new code.
2) I get the strong feeling that it's going into contrib only because it
missed feature freeze. If it hadn't missed feature freeze, it wuold be in
the backend and not contrib. If the plan is that it lives in contrib
forever, that argument falls. But if the plan is to migrate it into the
backend for 8.4, then I strongly object to using contrib just as a way to
"get it in even though we're feature-frozen".
yeah I agree that code like this should be either in core or somewhere
else (either pgfoundry or even shipped as part of the replication
solutions mentioned which is basically something slony did for ages with
the xxid stuff). Just pushing it now into contrib results in people
wanting to use one of those solution having to deal with 3 kinds of
packages:
1. postgresql
2. postgresql-contrib
3. skytools/slony/...
instead of just two which does not strike me as much of an improvement.
Stefan
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
