Re: Is it time for triage on the open patches? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Is it time for triage on the open patches?
Date
Msg-id CA+U5nM+1pOPtOJKoP+bsCfu263PtVTvKz-hhQj8FBaN+3mzCxQ@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?  (Robert Haas <robertmhaas@gmail.com>)
Re: Is it time for triage on the open patches?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Mar 9, 2012 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I think a reasonable way to proceed might be to get some consensus on
> a short list of patches we're willing to try to push to completion,
> then set a schedule accordingly, and then anything that doesn't get
> done by the deadline gets kicked to 9.3.
>
> Or we can just keep drifting.  But the number of open patches that
> are *not* Ready for Committer, nigh two months after the CF started,
> is depressingly large.


* FOR KEY SHARE locks looks in very good shape and so I'm spending
time on that with a view to committing it next week if all goes well

* pg_stat_statements looks good also, I hope someone is looking at that

It's a good thing we have so many patches. We just need to organise
ourselves to ensure that we're working on priority items and spot
important things that are receiving no attention.

At this stage the CF app isn't helping us much. We need some way to
indicate who is actively working on review, not just a list of people
who have at some point reviewed it. Patches without committers will
likely suffer, so we need to be able to see the Committers column on
the display, so we know whether a patch needs one assigned.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Next
From: Artur Litwinowicz
Date:
Subject: Re: elegant and effective way for running jobs inside a database