Very good point, but I’m not sure that CTR is that much less ambiguous. It would be interesting to compare different models both that users consider CTR as well as RTC. I have a feeling there is some overlap of “CTR” and “RTC”.
I’m pretty sure that a lot of folks call some CTR cases “RTC”. It’s pretty hard to review changes which are not in a source control system some way or another. Attaching a patch to a JIRA is a pretty clunky way of going about that. In particular, I’m interested in knowing how much “R” prior to “C” people have trouble with (Greg specifically as he seems to be the most vocal in his opposition). What workflows do “CTR” proponents like to use? Thanks, Harbs On Nov 25, 2015, at 6:47 PM, Upayavira <u...@odoko.co.uk> wrote: > Not replying to this mail specifically, but to the thread in general... > > People keep using the terms RTC and CTR as if we all mean the same > thing. Please don't. If you must use these terms, please define what you > mean by them. > > CTR is a less ambiguous term - I'd suggest we all assume that "commit" > means a push to a version control system. > > However, RTC seems to mean many things - from "push to JIRA for review > first, wait a bit, then commit to VCS" through "push to JIRA, and once > you have sufficient +1 votes, you can commit" to "push to JIRA for a > review, then another committer must commit it". > > If we're gonna debate RTC, can we please describe which of these we are > talking about (or some other mechanism that I haven't described)? > Otherwise, we will end up endlessly debating over the top of each other. > > Upayavira > > On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote: >> AIUI, there’s two ways to go about RTC which is easier in Git: >> 1) Working in feature/bug fix branches. Assuming RTC only applies to the >> main branch, changes are done in separate branches where commits do not >> require review. The feature/bug fix branch is then only merged back in >> after it had a review. The reason this is easier is because branching and >> merging is almost zero effort in Git. Many Git workflows don’t work on >> the main branch anyway, so this is a particularly good fit for those >> workflows. >> 2) Pull requests. Using pull requests, all changes can be pulled in with >> a single command. >> >> I’ve personally never participated in RTC (unless you count Github >> projects and before I was a committer in Flex), so it could be I’m >> missing something. >> >> Of course there’s nothing to ENFORCE that the commit is not done before a >> review, but why would you want to do that? That’s where trust comes to >> play… ;-) >> >> Harbs >> >> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <c...@apache.org> wrote: >> >>> I don't think Git is particularly empowering RTC - there's nothing in it >>> that >>> requires someone to look over one's shoulder. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
