Robert Haas wrote:
>> 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.
Agreed. I've tried to do a quick review and give early feedback on the
big patches, concentrating on high-level, architectural issues, so that
authors of big patches don't need to twiddle their thumbs waiting for
review.
OTOH, more detailed review at early phase is not a very good use of time
if there's design issues to be resolved, and author is still working on it.
> 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 don't have suggestions, but I'd just like to say that you Robert, have
given extremely valuable feedback. And on many patches too, I have been
very impressed throughout the commitfest. Thank you!
I'm not sure how much round-robin-review has taken load off committers,
you have to read and understand a patch before committing anyway. It has
helped, for sure, but not dramatically. However, I think that it has
made a big difference from authors point of view; you get feedback earlier.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
