Re: Is it time for triage on the open patches?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Subject: Re: Is it time for triage on the open patches?
Date: 2012-03-09 20:08:07
Message-ID: CA+TgmoaTkrO-Mpq7x=zeq_MBMeCTTQe9Nt=R3B=Ec2pokOFbDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 9, 2012 at 2:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This is a fair position, but I think it's a bit unfair to be applying
> such pressure to just the command-triggers patch and not all the other
> open issues.  Hence, $SUBJECT: is it time to start forcing this
> commitfest to a conclusion, and if so what kind of schedule are we
> trying to set?

Just to be clear, it wasn't my intention to hold command triggers
specifically to a different standard - but I do differentiate between
small patches and big patches. Small patches that someone can get
committed with an hour's worth of review can be treated a little more
leniently than large patches that may take many cycles of review
adding up to days of effort, and I believe command triggers to be one
such patch.

> Personally, the open patches that I'm excited about getting into the
> tree (or at least trying hard to) are:
>        * NULLs support in SP-GiST
>        * Caching constant stable expressions per execution
> and not that much else.  (I'm also interested in the pgsql_fdw patch
> but I'm afraid that getting it to committable shape in the next week
> or two may be unrealistic.)  Probably other people have their own,
> different shortlists.

I'd like to get the two sepgsql patches done if possible. I'm going
to commit the rest of the DROP patch shortly, and the GUC for client
label I will review and commit if it seems like it's in good shape. I
would *like* to see Heikki's XLogInsert scaling patch committed, but
it seems like it's still too buggy for that, and I'm not sure how long
we should wait for it to get fixed; I also don't have plans to work on
it personally. It's hard to pick favorites among the rest; there are
a number of things I'd like to work on, but if it's just me working on
them it's going to take longer than I want to wait for them to get
done. There's been very little patch review going on, with a couple
of notable exceptions like Thom and Noah, and not a lot of new patch
versions from patch authors either, again with a few exceptions, like
Dimitri. So it's not terribly surprising that progress is very slow.
I'm not sure what to do about that, either: it doesn't seem very fair
to start booting patches things that are in relatively good shape, but
on the other hand I'm not willing to single-handedly (or even with
both hands) take on the task of reviewing everything that nobody else
is paying attention to.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yeb Havinga 2012-03-09 20:09:43 Re: [v9.2] Add GUC sepgsql.client_label
Previous Message Tom Lane 2012-03-09 20:04:23 Re: xlog location arithmetic