> 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
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.
PostgreSQL Experts Inc.
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2009-06-30 18:41:58|
|Subject: Re: 8.5 development schedule|
|Previous:||From: David E. Wheeler||Date: 2009-06-30 18:36:41|
|Subject: Re: Inconsistent Errors on Row Comparisons |