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