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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
