incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Wed, 25 Nov 2015 20:44:20 GMT
What about commit to feature/bug brach, review and then commit to main branch?

Is that CTR or RTC in your book?

On Nov 25, 2015, at 10:42 PM, Greg Stein <> wrote:

> I object to Lucene's path, too. A committer's judgement is not trusted
> enough to make a change without upload/review. They need permission first
> (again: to use your term; it works great).
> On Wed, Nov 25, 2015 at 2:39 PM, Upayavira <> wrote:
>> 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 <> 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 <>
>> 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:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message