Re: Rethinking the parameter access hooks for plpgsql's benefit

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" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit
Date: 2015-03-09 19:06:24
Message-ID: CA+TgmoYUMWfc=cSvXwAajnPgbr3br3MTz5AVnG+uW9G7ffapsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 9, 2015 at 2:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Yes, I understand. I don't really have anything more to say about
this. Nothing here changes my basic feeling that we need to stop
putting new irons in the fire and start working hard on taking irons
out of the fire; and I think most if not all other committers are
already doing that. Even to the extent that they are focusing on
their own patches rather than other people's patches, I think it is
mostly patches that they wrote some time ago, not new things that they
have only just written.

I also will say, in fairness, that I do not really care about this
particular patch all that much one way or the other. I am less
convinced than you that this will always work out to a win, but when
it comes right down to it, you're a pretty smart guy, and if this gets
complaints about some scenario you've overlooked, I have confidence
you'll get around to repairing it. So whatever. What I do care about
is that we as a project have to at some point be willing to begin
closing the spigot on new patches and focusing on polishing and
shipping the patches we've already got. I think it's perfectly
reasonable to worry about where we are on that continuum when it's
already several weeks after the start of the last CommitFest, but if
I'm in the minority on that, so be it. But it's got to be done at
some point, or we will not be able to ship a beta, or a release, on
the anticipated timetable.

--
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 Peter Geoghegan 2015-03-09 20:15:59 Re: Rethinking the parameter access hooks for plpgsql's benefit
Previous Message Tom Lane 2015-03-09 18:54:18 Re: Calling for a replacement committer for GROUPING SETS