> 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
