"Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster