Robert Haas <robertmh...@gmail.com> writes: > On Mon, Mar 9, 2015 at 12:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> JD sees the situation correctly: this is $dayjob work, and it's going >> to get done now not in four months because I have a deadline to meet. >> I would like to push it into the community sources to reduce divergence >> between our copy and Salesforce's, but if I'm told it has to wait till >> 9.6, I may or may not remember to try to do something then.
> Sure, I have things that I've wanted to push into the community > sources for the benefit of EnterpriseDB, too. Nobody's offered to let > me ignore the community process when it happens to be good for > EnterpriseDB. If we're changing that policy for patches submitted by > Salesforce employes, I'm afraid I must object unless EnterpriseDB > employees will get the same privilege. And I think 2ndQuadrant will > want in on it, too. As far as that goes, it has never been the case that we expected every patch to go through the commitfest review process. (If we did, our response time to bugs would be probably a couple orders of magnitude longer than it is.) The way I see the policy is that committers have authority to commit things that they feel are ready and that haven't been objected to by other developers. Depending on the particular committer and the particular patch, feeling that a patch is "ready" might or might not require that it's been through a commitfest review. There is no process-based restriction on committing "ready" patches except when we are in alpha/beta/RC states, which is surely months away for 9.5. If I were looking for a formal review on this one, I would certainly not expect that it would get one during the current CF. I wasn't though. For context, I have currently got half a dozen irons in the fire: * "expanded objects" (array performance fixes): needs review, was submitted timely to current CF * operator precedence changes: committable IMO, but it's not entirely clear if we have consensus * adjust loop count estimates for semijoins: committable IMO, waiting for objections * find stats on-the-fly for children of UNION ALL appendrels: WIP, far from done though * flatten empty sub-SELECTs and VALUES where feasible: committable IMO, waiting for objections * parameter fetch hook rethink: WIP, not as close to done as I thought last night I wasn't really planning to use the CF process for any but the first of these. If we start insisting that committers go through CF for even rather small patches like these other things, it's going to destroy our productivity completely. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers