Some setups that people call RTC are actually CTR in your nomenclature, so we could be talking cross-purposes. That's all I'm trying to avoid. E.g. Lucene - everything happens in JIRA first (upload patch, wait for review), but once that has happened, you are free to commit away. So strictly, it is RTC, but not seemingly in the sense you are objecting to.
Upayavira On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote: > I think this is a distraction. You said it best the other day: RTC > implies > the need for "permission" before making a change to the codebase. > Committers are not trusted to make a judgement on whether a change should > be made. > > CTR trusts committers to use their judgement. RTC distrusts committers, > and > makes them seek permission [though one of several mechanisms]. > > -g > > On Wed, Nov 25, 2015 at 10:47 AM, 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
