Re: [HACKERS] Patches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Patches
Date
Msg-id 7814.917804459@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Patches  ("D'Arcy" "J.M." Cain <darcy@druid.net>)
Responses Re: [HACKERS] Patches  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
"D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> I see that Marc has gone ahead and committed it now.  I guess the problem
> is multiple queues.  It would be better if there was one queue that the
> committers could work on but I can't think of a good way to make that
> work.  Maybe some sort of PR system.

I don't think multiple queues per se are a problem; the deficiency I see
in our patching procedures is lack of visibility of the status of a
proposed patch.  If it's not been applied, is it just because no one
has gotten to it yet, or was there an objection from someone?  What's
worse is that one of the people with commit access might miss or forget
about such an objection, and commit a bogus patch anyway sometime later.
We have enough committers now that I think there's a definite risk here.

If we wanted to be really organized about this, it'd be cool to have
a central database with an item for each proposed patch and links to
followup discussions.  But I'm not sure it's worth the work it would
take to set it up and then maintain the entries.  Unless we get badly
bitten by a mistake that such a database would've prevented, it probably
won't happen ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: vacuumdb?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: Reducing sema usage (was Postmaster dies with many child processes)