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

On Wed, 10 Oct 2007 21:02:30 +0100
Gregory Stark <stark@enterprisedb.com> wrote:

>
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>
> > There are quite a few contributors that are upset that this whole
> > process went down the way that it did. I would say they are likely
> > in the majority versus the people that just want to leave it alone
> > and move on.
>
> >   That means it is not complete. Which means we might as well look
> > at Concurrent psql, Table function support, bitmap scan changes,
> > and GIT as well.
>
> That's just nonsense. We need to fix our other problems too and that
> means getting substantive feedback to the authors of those patches so
> they can complete the work. But that has no bearing whatsoever on the
> current situation.

You seem to be diverting my point. We can not provide preferential
treatment. Those patches are out there and have been out there for some
time. They followed the rules. Frankly, they deserve to be fully
reviewed and have the opportunity to be put in core *before* this
contrib patch.

Especially since this patch has already been marked as *not complete*.
There is already discussion happening on the patch and the changes that
need to be made.

>
> > Another option, is to push the contrib module to pgfoundry. There is
> > zero loss here to PostgreSQL that I can see, in the current state
> > of the patch.
>
> You keep saying this, do you have any justification for it?

I believe if you read my posts I have made plenty of justification. The
simplest of course being, process wasn't followed.

>
> I've explained why I think this code belongs in Postgres and not
> pgfoundry, did you have any counter-argument?

I believe I have mentioned that there is an argument for it to be in
PostgreSQL.

>
> And the complaints Tom brought up are mostly precisely the kind of
> interface issues that actually argue well for it being in contrib.

Nothing that is in contrib can not also be maintained just as well with
pgFoundry. It just may take more proactiveness in the process.

> It
> serves its current purpose well but future users might need binary
> i/o or subxid support and so on. Until the interface is very stable
> being in contrib makes perfect sense.
>

I would state that until the interface is very stable pgfoundry also
makes perfect sense.

I am getting the impression that you think that I don't *want* this
module. I do, but I do not want it at the sacrifice of other modules
and code authors who did the job the right way.

I understand Tom's point about if we push to 8.4 that could cause
problems for Slony and Skytools. I certainly don't want to cause
problems for some very cool projects. I do however don't see those
problems existing if it was in pgFoundry.

Or are we saying that the only way to provide quality sofware to
PostgreSQL is if it is either in core or contrib? I do not believe you
are saying that.

Sincerely,

Joshua D. Drake






--
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/        UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/