RTC? CTR? How about RTCTR!
January 10th, 2008 by HenNoticed something the other day while doing some Commons coding.
While at SourceLabs, I got in the habit of attaching my fixes to the JIRA issues before commiting them. This was for two reasons - first it was intended to be a way to remind myself which issues I worked on in the dayjob and which in the nightjob; and second it made it easier for me to apply them to SourceLabs versions if the upstream version didn’t get released. The first reason didn’t stay true completely as I got used to attaching the patches even in the evening.
What I’ve noticed is that I still do it. Furthermore, others seem to do it too though I’ve no idea if I influenced that, or if it was already going on.
Let’s take a step back and discuss the acronyms in the title. Apache Projects operate under either Review-Then-Commit (RTC) or Commit-Then-Review (CTR). Generally it seems that CTR is the usual - namely you commit and others are reading your svn commit when it hits the email list. If they disagree, they complain. Some projects use RTC, which is when you discuss the patch and then apply it - usually it seems either because there’s a lot of emotive feeling on the subject and they want to avoid a commit war, or because the code is very stable and they want to keep it so.
Commons uses CTR, or at least it used to. Now, with this trend towards taking patches through the issue tracker for at least some of the components, we’re doing RTC in a CTR environment and ending up with RTCTR. Namely, a subset work on the JIRA issue, reviewing the patch, and then the whole can do review on the commit when it goes in. ReTraCToR.