Re: Skytools committed without hackers discussion/review

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Skytools committed without hackers discussion/review
Дата
Msg-id 20071011.102718.74742919.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Skytools committed without hackers discussion/review  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Skytools committed without hackers discussion/review  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
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.
--
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Artificially increase TransactionID?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Skytools committed without hackers discussion/review