I would propose to start CommitFests July 15th, September 15th, November 15th, and January 15th, planning all but the last to be one month long. The last CommitFest I would plan on closing up by March 1st, with release hopefully by June 1st.
This sounds good to me. Anyone object?
As for thresholds, I'd propose that we measure the size of patches using "diff -u | diffstat". If the number of insertions plus the number of deletions is>= 1000, then the patch is not eligible for the final CommitFest unless it was submitted for the penultimate CommitFest. This obvious discriminates against patches with a large footprint that are not very invasive and in favor of those with a small footprint that are more destabilizing, but it's a clean line in the sand, and I think having such a line is better than trying to apply human judgment to every case.
I think we need human judgement. You could easily make a 4-line change to a macro or one of the planner files which would require endless debugging.
The deciding people on "big patches" for the final commitfest should be a combination of the commitfest managers and the core team. And we should weed out the disqualified before January 15.
-- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
