Re: Rethinking the parameter access hooks for plpgsql's benefit - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rethinking the parameter access hooks for plpgsql's benefit
Date
Msg-id 17376.1426627710@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rethinking the parameter access hooks for plpgsql's benefit  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Rethinking the parameter access hooks for plpgsql's benefit  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 17, 2015 at 1:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> My understanding has been that for the last 5 years, the feature
> freeze deadline, for both committers and non-committers, is the
> beginning of the last CF, and earlier for "major" patches, most of
> which tend to come from committers.

Um, I consider that "feature freeze" marks a point at which we stop
*committing* new features, not a point after which new features can
no longer be submitted or considered.  Otherwise we'd be spending
four or more months a year in feature freeze, and that just isn't
appropriate IMV.

In any case, I reject the notion that the CF process has anything to
do with that decision.  The point of the CF submission deadline is
that we promise to consider every submission made before the deadline.
It is not to forbid committers from taking up items that arrived later,
if they feel motivated to.
        regards, tom lane



pgsql-hackers by date:

Previous
From: hitesh ramani
Date:
Subject: Re: GSoC 2015: Introduction and Doubt regarding a Project.
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0