Trick question, as I'd never work under that model :-)

Apache Subversion is CTR, with a very low bar to get commit access to
portions of the tree or a branch (only PMC members get access to whole
tree, so we grant full access and PMC membership simultaneously). We don't
need a fancy label for "contributor who is a committer" because such a
concept is anathema to the Subversion community's peer respect model.

On Thu, Nov 19, 2015 at 6:38 PM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> Greg, which of these do you use when the “contributor” is a committer?
> Remember the model here is that the author is never allowed to commit their
> own code.
>
> Ralph
>
> > On Nov 19, 2015, at 3:10 PM, Greg Stein <gst...@gmail.com> wrote:
> >
> > The Apache Subversion project does something similar:
> >
> >
> http://subversion.apache.org/docs/community-guide/conventions.html#crediting
> >
> > We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
> > On Nov 19, 2015 1:57 PM, "Chris Nauroth" <cnaur...@hortonworks.com>
> wrote:
> >
> >> Some projects use the git Signed-off-by field in the commit log to
> >> differentiate the author from the reviewer.
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 11/19/15, 10:58 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
> wrote:
> >>
> >>> And there is another problem I have. Maybe it isn¹t true of all
> projects,
> >>> but the one I am involved with says the author can¹t commit his own
> code.
> >>> So the commit logs will not reflect who actually authored the code but
> >>> who reviewed it.
> >>>
> >>> I could probably tolerate RTC if I had to have the commit somewhere it
> >>> could be reviewed, I had to wait for the review and fix any defects and
> >>> then could commit the code myself (ideally even if no one actually
> >>> reviewed it). That process isn¹t really much different than what I do
> for
> >>> my larger commits anyway. But just submitting something for review and
> >>> then hoping someone reviews it and then hoping someone commits it takes
> >>> all the joy out of it for me.
> >>>
> >>> Ralph
> >>>
> >>>> On Nov 19, 2015, at 10:10 AM, Todd Lipcon <t...@cloudera.com> wrote:
> >>>>
> >>>>
> >>>> Sure, that's a big problem with some RTC workflows. Using gerrit or
> >>>> github
> >>>> PRs makes the flow much easier -- for a trivial or small patch, the
> sort
> >>>> that a "drive-by" contributor typically contributes, there probably
> >>>> won't
> >>>> be any review comments. So, they just push the patch for review, and
> >>>> they
> >>>> can be out of the loop for the rest of it. If the patch requires small
> >>>> revisions (eg addressing a typo or something) I think it's fine for
> the
> >>>> reviewer to just make the change themselves and commit on behalf of
> the
> >>>> original author to avoid the issue you've raised. Most RTC workflows
> >>>> permit
> >>>> this kind of thing in my experience.
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
>

Reply via email to