"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> [ thinks for a bit... ] A truly hard-nosed approach would be to define
> FF as "if your patch isn't committed by the FF date, you lose". The
> FF-to-beta delay then is only long enough to make sure we've documented
> everything, written release notes, etc.
You're assuming nothing committed could possibly be broken. I think "normal"
feature freeze semantics are that you freeze adding new features so you can
get the features that are committed working properly.
While it's nice that we have such a high standard for the patches that are
committed it's also kind of limiting us. For example, I think it worked pretty
well when you committed HOT and then based on experience and discussion added
the per-page xid. Insisting on every patch being 100% perfected before it gets
committed makes it hard to collaborate since it limits the visibility of the
work in progress.
I do understand the concern that committing lots of broken or partial patches
will make it hard for others to work on unrelated work and make for lots of
work cleaning up the tree later. Tools like git/monotone/svk might help there.
But even with CVS there ought to be a better tradeoff than pushing all the
development into patches and requiring the CVS tree to be 100% perfected
complete patches. Working with patches over email is painful.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
