I can see advantages to both CTR and RTC. For bugs and even modest changes, yes CTR seems fine. Recent examples where I would have preferred to do that include:
https://issues.apache.org/jira/browse/CHUKWA-517 https://issues.apache.org/jira/browse/CHUKWA-518 https://issues.apache.org/jira/browse/CHUKWA-519 Bigger changes though, especially ones that have an external face on them, like the recent REST API features, are good to have more of a feedback gathering RTC phase, like these: https://issues.apache.org/jira/browse/CHUKWA-515 https://issues.apache.org/jira/browse/CHUKWA-520 A few questions a have though about CTR: - Bernd, from your initial comments it sounds like in some cases you don't even have a JIRA filed with the commit. Is that the case? I've always thought that a commit should really have a JIRA just for tracking, but I can change that thinking. Can you elaborate on how you see JIRA playing into CTR? - Similarly, it sounds like patches aren't needed with CTR. The downside of this is that others can't easily apply the patch to a release distribution and rebuild (something I do all the time). I'd think if it's worth committing, it's worth having a patch file for others to apply. Any thoughts around this? I generally like the discussion around how to become more agile though, since I see many benefits to be had there. I recently skimmed some of the CTR discussion on the apache site and thought to myself that that sounds different than what we're doing. On Mon, Sep 13, 2010 at 1:14 PM, Ariel Rabkin <[email protected]> wrote: > > 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 > fairly cursory. > > 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"? > > --Ari > > On Mon, Sep 13, 2010 at 12:58 PM, Bernd Fondermann > <[email protected]> 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. > > > > Thanks, > > > > Bernd > > > > > > -- > Ari Rabkin [email protected] > UC Berkeley Computer Science Department
