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 <u...@odoko.co.uk> 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 <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 > >
