That is pretty normal operation in both styles of workflow. My concern is with trunk/master. Is a committer trusted enough to make changes directly?
If all meaningful changes (ie. changing APIs and algorithms, not just fixing typos w/o review) are not trusted, and require review/permission, then I'm against that. It is good practice to put potentially disruptive code onto a branch while it is developed, then merge it when complete. Trusting a committer to ask for review before the merge is great. Requiring it, less so. But RTC on trunk/master is harmful. Cheers, -g On Wed, Nov 25, 2015 at 2:44 PM, Harbs <harbs.li...@gmail.com> wrote: > 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 <gst...@gmail.com> 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 <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 > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
