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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "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-17 17:28:21
Message-ID: 10144.1426613301@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> What I was complaining about is new feature patches for 9.5 arriving
> after the start of the last CF. There has to be some date after which
> a patch is too late to be considered for a given release, or we will
> never ship a release. We can argue about what that date is, and it
> can be different for different people if we so choose, but at the end
> of the day, you have to cut it off someplace, or you never get the
> release out.

Well, I'm going to push back on that concept a bit. I do not think the
CF process is, or ever has been, meant to tell committers they can't work
on things at times they find convenient. That would be holding back
progress to little purpose. What the CF process is about is making sure
that things don't slip through the cracks, and in particular that
submissions from non-committers get due consideration on a reasonably
timely basis.

We do have a process in which even committers have to think twice about
whether it's appropriate to push something, but that's feature freeze
during alpha/beta/RC testing, and we are still a long way away from that
stage for 9.5.

Or in short: yes, the rules are different for committers and non
committers. That's one of the reasons we are slow to hand out commit
bits.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-03-17 17:29:24 Re: Strange assertion using VACOPT_FREEZE in vacuum.c
Previous Message Stephen Frost 2015-03-17 17:27:49 Re: Rethinking the parameter access hooks for plpgsql's benefit