Bernd Fondermann 2010-09-13, 19:58
Our methodology is actually some hybrid; something like "wait for
potential review", then commit. Usually I'll commit after a few days
if nobody objected or commented. (I try to say explicitly when I'll
time out waiting for comments.) And most of the patch review is
I agree that the full rigor of RTC is probably unnecessary. I do like
it, however, for bigger changes, particularly those that alter the
architecture or user visible feature set.
Is it reasonable to say "for bugs, CTR is fine, and only file a JIRA
and wait for review if it's going to break something"?
On Mon, Sep 13, 2010 at 12:58 PM, Bernd Fondermann
<[EMAIL PROTECTED]> wrote:
> 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.
Ari Rabkin [EMAIL PROTECTED]
UC Berkeley Computer Science Department
Eric Yang 2010-09-13, 20:49
Bill Graham 2010-09-13, 20:50
Bernd Fondermann 2010-09-14, 10:17
Bill Graham 2010-09-14, 21:22
Jerome Boulon 2010-09-21, 05:00
Jiaqi Tan 2010-09-21, 05:12
William A. Rowe Jr. 2010-09-21, 05:55
Ariel Rabkin 2010-09-21, 20:50
William A. Rowe Jr. 2010-09-21, 21:38