Re: Skytools committed without hackers discussion/review

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Marko Kreen <markokr(at)gmail(dot)com>, Michael Glaesemann <grzm(at)seespotcode(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Skytools committed without hackers discussion/review
Date: 2007-10-10 17:05:28
Message-ID: 20071010100528.441c42db@scratch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, 10 Oct 2007 11:04:53 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
> >> Now txid can change that. E.g. in Skype, it has become
> >> irreplaceable tool for coordinating work between several
> >> databases. Here we are probably going overboard with usage of
> >> queues...
>
> > If it is this irreplacable killer feature, it should *not* be in
> > contrib. It should be in the core backend, and we should be
> > discussing if we can bend the rules for that.
>
> It may be a killer feature for Skytools and Slony, but even so that's
> a small part of our userbase.

This is a valid point. Skytools is cool. Slony is cool, but their user
bases compared to PostgreSQL proper are miniscule. We need to be
considering the potential issues (if there are any) that this can cause
for the larger community.

I can think of a couple of immediate ones, I believe Tom has touched on
some of these elsewhere in the thread.

1) Maintainability
2) The eventual (lord it is about 5 years late) upgrade in place feature
3) This possibly should be in core not contrib.

*If* it should be in core, it needs to push to 8.4. It is that simple.
Else we need to open the tree and start reviewing all those patches
that got left behind before at feature freeze because of possible open
issues.

If it doesn't need to be in core, in certainly has zero need to be in
contrib and can push to pgFoundry.

>
> I think our two realistic options today are (1) leave the code where
> it is, or (2) remove it. While Jan clearly failed to follow the
> agreed procedures, I'm not convinced the transgression was severe
> enough to justify (2).

Well I would like to step back and remove the Jan element. Jan has
really been taking a beating here. The reality is, A "committer" made a
mistake. It doesn't matter who it was.

The code needs to be removed. I just don't see a way around it,
unless we are willing to go back and review other items. This patch has
not been peer reviewed, it's benefit has not been discussed on
-hackers, and in general it hasn't been vetted.

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/

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Joshua D. Drake 2007-10-10 17:10:58 Re: Skytools committed without hackers discussion/review
Previous Message Gregory Stark 2007-10-10 17:01:34 Re: Skytools committed without hackers discussion/review

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-10-10 17:10:58 Re: Skytools committed without hackers discussion/review
Previous Message Gregory Stark 2007-10-10 17:01:34 Re: Skytools committed without hackers discussion/review