Re: Skytools committed without hackers discussion/review

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: Skytools committed without hackers discussion/review
Дата
Msg-id 20071010115756.0c82208c@scratch
обсуждение исходный текст
Ответ на Re: Skytools committed without hackers discussion/review  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Skytools committed without hackers discussion/review  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Hello,

Well this certainly turned into something bigger than I thought it ever
would. The questions that come into play with this whole thread are
larger than just, "the process wasn't followed, what do we do?"

We obviously don't want to make life difficult for our sibling projects
such as Slony and Skytools. On the other hand, we certainly want
processes followed because it leads to better overall quality control.
It also leads to fairness within community as a whole.

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.

As I see it, we really only have a couple of choices:

Allow it as contrib which isn't really a good solution because,
Tom and others have piped up that this may need to be in core. If it is
to go into core we have two choices, back off beta and
review some of those last patches that were kicked or... push it to 8.4.
 Why? Because people are already talking about changes to this
patch such as supporting binary I/O and helper functions that don't
exist in the current piece of code.
 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.
 Those patches were submitted long ago and tried to go through the
correct process and have been pushed to 8.4. Now, some of them may need
more work than is warranted (I can't actually speak to that) but
certainly a couple of them are worth a second look.

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. It just means that the two projects supporting this patch
(Skytools and Slony) will have to cooperate. They have already proven
they can do this.

Of course this doesn't solve the should be in core issue but the should
be in core came about *after*.

Either way, I think everyone has had there say. Can we just make a
decision. Personally I think we should just push to pgfoundry and call
it good.

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/


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

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: Skytools committed without hackers discussion/review
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as