> I am just explaining how it works in practice. If the patch is still > being improved, the feeling is that the author wants more time to adjust > things, and with other things on our plate, we are glad to leave their > patch until last.
Well, it's good that you have an explanation, but I'm not sure it helps much. :-) Surely the patches that are most likely to change substantially are the big ones, and leaving those until last results in them not making the time-based cutoff. Someone who submitted a 20-line patch isn't likely to revise it substantially; someone who is being paid $20k to write a patch is likely to spend a lot of time working on it. I think the fundamental problem here is the number and bandwidth of the committers, which seems to be pretty limited. Most of the committers are either inactive, or essentially maintainers for a particular subsystem. With the exception of patches authored by the committers themselves, I think the vast majority of patches for this 'fest were committed by Tom and Peter - and I think really mostly Tom. And many of those were significantly modified in the process of being committed, which suggests that efforts to take the load of committers by having non-committers do reviews has not been entirely successful. (It would be interesting to here how much value people think it has added, and get suggestions on how to do things better next time.) I'm not sure what to do about it, though. More committers could be added, but I presume if there were obvious candidates it would have been done already. It's complicated by the fact that you need people who both (1) know what they're doing and (2) have time to review and commit *other people's patches*. In reality, a pretty significant fraction of the current committers are either mostly inactive, or essentially maintainers for one small area of the code. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers