Tom Lane wrote: > > 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. > > Well, in the end it will come down to committers' judgements anyway; > if someone thinks a patch is ready it will probably go in, regardless > of size. But this gives us another tool for saying "no", so I'm > agreeable ;-)
I realize there is the perception that the large patches that were eventually rejected held up the release, but for all the patches I can think of, they were not rejected immediately _because_ we had other valid patches to work on. Once all valid patches were applied, we were quickly able to reject the large unready patches. So, rejecting the large patches earily would not have significantly moved the release date earlier. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers