From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: commit fests (was Re: primary key error message) |
Date: | 2010-01-22 16:19:15 |
Message-ID: | 1847.1264177155@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:
> I'm not sure whether you're stating a position that's been agreed to
> by -core or some other group, or just expressing your own opinion, but
> I think feature freeze should be the beginning of the last CommitFest,
> not the end.
I think traditionally we understood "feature freeze" to be the point at
which we stopped *committing* new features, not the point at which it
was too late to *submit* them. So by that definition feature freeze
starts at the end of the last CF.
I agree with Peter that things are a bit different in the CF process.
Rather than a binary frozen-or-not state, we now have a gradual
congealing (if you will), where the size of an acceptable new feature
gets smaller as we get towards the end of the development cycle.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-01-22 16:19:55 | Re: Access to dynamic SQL in PL/pgSQL |
Previous Message | Aidan Van Dyk | 2010-01-22 15:57:52 | Re: 8.5 vs. 9.0, Postgres vs. PostgreSQL |