My sense is that there's virtually never feedback on patches prior to commit. There is, however, often feedback on design choices before the patch is posted.
I assume even with commit-then-review there would still be review for major change proposals before implementation. --Ari On Mon, Sep 20, 2010 at 10:55 PM, William A. Rowe Jr. <[email protected]> wrote: > On 9/13/2010 2:58 PM, Bernd Fondermann wrote: >> Hi, >> >> If I understand correctly, Chukwa is following the review-then-commit >> (RTC) pattern: Before every commit, a patch gets posted to a JIRA and >> only on positive feedback it is committed. >> As far as I can see, this is inherited from Hadoop's policies. >> However, most projects at the ASF apply commit-then-review (CTR). CTR >> has the advantage of being more agile, requiring less work (creating >> issue, patch file, attaching it, waiting for feedback etc.) while >> providing full oversight: >> Every commit is reviewed by other committers after it happened, can be >> discussed, reverted, improved etc. as a 'work in progress'. >> It is best practice in CTR-mode to selectively use RTC, e.g. for big >> patches or for potentially delicate commits. >> >> I think Chukwa would profit from changing to CTR, so I'd like to know >> what you think about it. > > The only useful question is what % of the jira tickets are rejected, or > corrected, prior to commit? If this number is very low, I'd suggest that > waiting for jira feedback before committing is a waste. As this number > grows larger, the amount of work undone in trunk becomes more onerous > than the review of open jira tickets. > -- Ari Rabkin [email protected] UC Berkeley Computer Science Department
