Re: Is it time for triage on the open patches? - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Is it time for triage on the open patches? |
Date | |
Msg-id | CA+TgmoaTkrO-Mpq7x=zeq_MBMeCTTQe9Nt=R3B=Ec2pokOFbDA@mail.gmail.com Whole thread Raw |
In response to | Is it time for triage on the open patches? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Is it time for triage on the open patches?
Re: Is it time for triage on the open patches? |
List | pgsql-hackers |
On Fri, Mar 9, 2012 at 2:47 PM, Tom Lane <tgl@sss.pgh.pa.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
pgsql-hackers by date: