On Sun, Jan 11, 2015 at 1:34 PM, Joe Witt <[email protected]> wrote:
> Apache Veterans, > > What is typical in a project trying to follow an RTC workflow? > > Benson's submission of a PR seems like an ideal way to do RTC. What > matt/mark/and I have largely done is put stuff in a branch which is often > overkill or generated a patch and appended that to a ticket. The Github PR > approach though seems like it might actually make more sense. > > Is there a 'common approach here'? > At Lucene, here is the PR workflow: Workflow 1: a committer submits a PR. a: committer attaches PR to JIRA b: community fails to complain for a few days c: committer merges to develop, including the magic incantation in the merge commit that causes the infrastructure to close the PR. Workflow 2: a non-committer submits a PR a: noncommitter attaches PR to JIRA b: community fails to complain c: committer merges to develop, including the magic incantation in the merge commit that causes the infrastructure to close the PR. No extra branches, no muss, no fuss. In both cases, committer has git repo with (at least) two remotes: the real Apache repo and the repo that the PR was launched from. > > Also, I personally have found RTC to be overkill for a non-trivial range of > changes: > - documentation updates > - license/header adjustments > - fixing maven configuration / build items > > I can see a bit of a slippery slope in the reasoning but is there merit to > defining things which are RTC vs those which are reasonable as CTR? > > Thanks > Joe >
