Re: commit fests (was Re: primary key error message)

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

In response to

Responses

Browse pgsql-hackers by date

  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