Andrew,
> I thought we discussed that at pgCon in May and rejected it.
That's not what we have in my notes:
http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#CommitFests
Of course, I may have missed some options, a lot of people were talking.
> I have very, very serious reservations about it. I think we need to get
> better about proper triage, especially on the final commitfest, rather
> than moving the effective feature freeze back a whole commitfest.
Thing is, if we're getting 15,000 lines of code we've never seen before
(collectively) at the final commitfest, there's simply no way we're
getting a release out within 3 months of that.
> ISTM we're in danger of becoming dominated by procedures. Let's keep it
> light and loose.
Hmmm ... actually, I think Andrew's right that we don't need a specific
"last commitfest" rule which is special. Really, any patch which gets
submitted to any commitfest gets returned if it's not ready to be
committed immediately after review. The only way the last CF is special
is that anything bounced goes to the next version.
We forgot that with the November CF, which is why it dragged on for 3.5
months and burned a lot of people out. Let's just stick to that this
time and we don't need any new rules.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
