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

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

Fine, call it a feature submission deadline.

> 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.

So this is really what it boils down to: you evidently think there is
no problem with new feature patches showing up a month or two after
the last CommitFest has started.  I do.  It distracts everyone from
focusing on the patches that were submitted earlier, so that they
don't get dealt with.  If the patch comes from a committer, it's
actually worse, because patches from non-committers can be safely
ignored until a committer expresses interest in them, but if the patch
is from a committer who obviously intend to push it along, you'd
better drop what you're doing and object pretty fast, or it'll already
be in the tree before you get around to it.  I think it's perfectly
appropriate for the project to have a feature submission deadline, I
think having such a deadline is important to both the timeliness and
the quality of our releases, and I think most people here understand
that deadline to be the start of the last CF.  I'm just repeating
myself here, so I'm going to shut up now.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
Next
From: Robert Haas
Date:
Subject: Re: parallel mode and parallel contexts