Joshua D. Drake wrote: > at seems like a bit of a whacky criterion to use before reviewing a patch. > > > > "wacky"? > > > >> It favours people who are short-sighted and don't see what possible > >> improvements their code has. No code in an ongoing project like this is > >> ever > >> "completed" anyways. > > > > It favors those who do not wait until the last minute, but complete them > > well before the freeze date. > > But wouldn't it hurt those that are continuously working the patch with > the community? Just asking.
Yea, it might, and it certainly hampers complex patches. I was caught up on the patch queue until the start of March, when I went on vacation, Tom started on cache invalidation, _and_ more complex patches started appearing. With those three, we had a perfect storm and the patch queue has gotten clogged, and I am afraid it isn't going to get unclogged until after feature freeze. I talked to Tom about this yesterday and he and I feel there isn't much we can do to change that, in the sense we are already doing the best we can, and clearing the remaining patches after feature freeze isn't that bad. One thing committers have to be willing to do is to give authors ample time after feature freeze to adjust patches after receiving feedback, because technically they should have received feedback _before_ feature freeze. Hopefully this will not significantly lengthen feature freeze. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
