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: