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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:29:14
Message-ID: 603c8f071001220829x4de68fdbv9f5a22b9d61b3b67@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 22, 2010 at 11:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

OK, fair enough.

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

Yeah, and I have no problem with that. I think I've already beaten
this horse to death, though, so I won't re-explain what I do think.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-22 16:33:37 Re: Access to dynamic SQL in PL/pgSQL
Previous Message Robert Haas 2010-01-22 16:27:56 restructuring "alter table" privilege checks (was: remove redundant ownership checks)