Re: Recovery Test Framework

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