bruce wrote: > 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 early would not have significantly > moved the release date earlier.
I see no one agrees with my analysis --- no matter; if I unreservedly agreed with others, I wouldn't be here. ;-) There has been discussion about how to be more hard-nosed about rejecting patches. I think it has to start with us being more hard-nosed about giving patches feedback --- the very idea we had to create commit-fests reflects that we historically have not done an organized job of processing patches. If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. -- 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