Hi,
Le 16 mars 09 à 21:41, Tom Lane a écrit :
Gregory Stark <st...@enterprisedb.com> writes:
I think it's clear that stretching feature freezes is a failed
policy.
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
I think Open Source showed that you can't have both time based
releases and feature based releases. Anytime any project try to
accomodate those two objectives, they fail at both.
It seems that PostgreSQL is leaning towards time based releases, which
I think made up the majority in our community. What I'd propose is to
refuse new patches posted in last two commit fests. Those are reserved
to bake what we release.
I'm not sure that's the best compromise you can do, even if it's
definitely one, but it has the merit to be quite clear and easy to
understand for contributors: you want your code to appear in X.Y, get
it reviewed at least once (with feedbacks) before we enter the last
but one commitfest. If you fail at this, you get to (try to) have your
code in X.Y+1, which won't be released that far away (about 1 year
away from a known date).
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
