Re: Skytools committed without hackers discussion/review - Mailing list pgsql-hackers

Magnus Hagander wrote:
> On Wed, Oct 10, 2007 at 11:50:12AM +0300, Marko Kreen wrote:
>> On 10/10/07, Joshua D. Drake <jd@commandprompt.com> wrote:
>>> On Tue, 9 Oct 2007 18:35:52 -0500
>>> Michael Glaesemann <grzm@seespotcode.net> 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