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

From Bruce Momjian
Subject Re: Skytools committed without hackers discussion/review
Date
Msg-id 200710110134.l9B1Y6j01347@momjian.us
Whole thread Raw
In response to Re: Skytools committed without hackers discussion/review  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
Tatsuo Ishii wrote:
> I don't undrestand why the txid stuff is in 8.3beta(this is an unsual
> case right?), but if we decide to keep it, please consider updating
> release.sgml. Bruce explained me that release.sgml will not be updated
> until the official release, but this is the unusual case and we need to
> break the rule, I think.

release.sgml is updated before every beta.

---------------------------------------------------------------------------


> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> 
> > Looking at the discussion, I think we should just keep it in /contrib. 
> > The code is tightly tied to our backend transaction system so there is
> > logic to have it in /contrib rather than pgfoundry.  I do think we
> > should just move it into core for 8.4 though.
> > 
> > ---------------------------------------------------------------------------
> > 
> > Joshua D. Drake wrote:
> > -- Start of PGP signed section.
> > > 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/
> > > 
> > -- End of PGP section, PGP failed!
> > 
> > -- 
> >   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
> >   EnterpriseDB                             http://postgres.enterprisedb.com
> > 
> >   + If your life is a hard drive, Christ can be your backup. +
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Skytools committed without hackers discussion/review
Next
From: Tom Lane
Date:
Subject: Re: Artificially increase TransactionID?