I think this is a good discussion to have, even if we decide not to change our process.
> The svn commit log and the chukwa-commit mailing list give you an easy way to access patches. I like the possibility of being able to commit without making a patch file and attaching it to a JIRA, so digging into this a bit more... Looking at "Subversion Commits" tab, let's use Eric's large CHUKWA-444 commit as an example. If he hadn't made a patch file, would there be an easy way for a Chukwa user to get a patch of the diff from JIRA (i.e., without having to check out the source and pipe an svn diff between the revisions to a file)? If so, that would be ideal. On Tue, Sep 14, 2010 at 3:17 AM, Bernd Fondermann <[email protected]> wrote: > On Mon, Sep 13, 2010 at 22:50, Bill Graham <[email protected]> wrote: >> 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? > > Before we had JIRA at the ASF (only bugzilla, which is no fun at all > IMHO), we did CTR without filing issues, of course. > Sometimes, patches where attached on-list. > Today, most projects indeed file a JIRA for everything, to benefit > from fully JIRA-generated release notes etc. > > CTR works great with JIRA: > + Create JIRA issue > + commit a patch, using the JIRA name ("CHUKWA-1234") in the commit log > message > + JIRA automatically detects and attaches the svn change log to the > issue (see the "subversion commits" tab in JIRA) > (+ iterate with more commits) > + Close the issue (, reopen etc.) > >> - 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? > > The svn commit log and the chukwa-commit mailing list give you an easy > way to access patches. > >> 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. > > Well, with this discussion thread I just meant to spin CTR. If RTC (or > any relaxed derivative thereof) is the way *you* as committers want to > go ahead, I definitively support it. > I don't mean to discrupt any well-established process just for the > sake of disruption. > > Bernd > >> 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 >> >
