Mailing List Archive

You'd still have to be voted in as a committer, but privileges could
certainly be partitioned easily to just branches if we wanted to make
it so narrowly constrained. And you'd be subject to the Apache CLA
paperwork too.

I think you've (*grin*) the level of contribution that calling for a
vote for your committership is in order anyway.

Erik

On Nov 2, 2006, at 11:30 AM, Michael McCandless wrote:

>
> Hi,
>
> Is it possible to allow non-committers (= me!) to commit only to
> branches in Subversion? Is such a thing even feasible, or ever done
> in other projects?
>
> I'm just asking because for something like the lockless commits patch
> it would be very helpful as I iterate with people (thanks Yonik!) who
> have reviewed it to be able to just commit my changes to a dedicated
> "private" branch and this way they can then just "svn up" or
> use "svn diff" to see only the diffs between my first patch &
> the fixes, etc.
>
> It would also have been helpful in the original development to have
> source control fallback as I was building out the first patch. It
> always makes me nervous accumulating long-living mods outside of
> source control in the first place. Better to commit often.
>
> It's obviously feasible to just keep re-submitting entire patches with
> each iteration but it sure would be nice to be able to use svn
> instead!
>
> Mike

Whoa, thanks for the vote of confidence Erik!!

I am interested in eventually becoming a committer (and I have
submitted my Apache ICLA) but I don't want to rush/force the process
or anything.

I was just wondering if there is a more lightweight approach in
between non-committer and committer that restricts rights to just
branches. Or even something like a committer creates the branch and
then grants commit access for just this one private branch to a
non-committer. It sounds like Subversion's per-directory
authorization controls could indeed support this use case but maybe
this is not typically done.

Mike

Erik Hatcher wrote:
> You'd still have to be voted in as a committer, but privileges could
> certainly be partitioned easily to just branches if we wanted to make it
> so narrowly constrained. And you'd be subject to the Apache CLA
> paperwork too.
>
> I think you've (*grin*) the level of contribution that calling for a
> vote for your committership is in order anyway.
>
> Erik
>
> On Nov 2, 2006, at 11:30 AM, Michael McCandless wrote:
>
>>
>> Hi,
>>
>> Is it possible to allow non-committers (= me!) to commit only to
>> branches in Subversion? Is such a thing even feasible, or ever done
>> in other projects?
>>
>> I'm just asking because for something like the lockless commits patch
>> it would be very helpful as I iterate with people (thanks Yonik!) who
>> have reviewed it to be able to just commit my changes to a dedicated
>> "private" branch and this way they can then just "svn up" or
>> use "svn diff" to see only the diffs between my first patch &
>> the fixes, etc.
>>
>> It would also have been helpful in the original development to have
>> source control fallback as I was building out the first patch. It
>> always makes me nervous accumulating long-living mods outside of
>> source control in the first place. Better to commit often.
>>
>> It's obviously feasible to just keep re-submitting entire patches with
>> each iteration but it sure would be nice to be able to use svn instead!
>>
>> Mike
>

On Nov 3, 2006, at 5:27 AM, Michael McCandless wrote:
> I was just wondering if there is a more lightweight approach in
> between non-committer and committer that restricts rights to just
> branches. Or even something like a committer creates the branch and
> then grants commit access for just this one private branch to a
> non-committer. It sounds like Subversion's per-directory
> authorization controls could indeed support this use case but maybe
> this is not typically done.

It's done frequently. In Lucene-land we have some committers that
only have rights to certain contrib sub-directories, for example. We
could easily do this for particular branches as well.

Erik

Erik Hatcher wrote:
> It's done frequently. In Lucene-land we have some committers that only
> have rights to certain contrib sub-directories, for example. We could
> easily do this for particular branches as well.

We actually have a set of contributors who only have access to the
entire contrib directory. This is for folks who primarily just maintain
a contrib module. We could make things more fine-grained, but that gets
messier to maintain.

It's about trust and community. Committers are folks who are trusted by
the community of other committers to make commits on their own. A
committer doesn't have to master all portions of the repository that
they *can* modify, only those that they *do* modify. We trust
committers not to modify things in areas where they're not fully
competent. It's therefore in theory reasonable to have committers who,
e.g., only maintain documentation or perform release management.

Trust is typically earned by developing a track record of commit-quality
patches. Each time a contributor says, "this patch is ready to commit"
they create a point of evaluation for themselves. If the patch is
committed with no modification, then they've earned credit towards
becoming a committer. (Significant patches and patches to core
components earn extra credit.) If other committers request some
modifications to the patch, and the contributor makes those changes,
then the committer is still learning what's expected. So, if you want
to be committer you should be careful about what you indicate is ready
for commit. That said, it's really not such a cold calculation. The
community comes to know and trust a contributor based primarily on
mailing list interactions, and the patch record merely provides assurances.

This is a long-winded way of saying that I don't think we ought to add a
committer for just a branch. If we trust someone sufficiently to let
them commit to a branch that we intend to merge into the trunk,
shouldn't we also trust them to not abuse the trunk? To some degree,
either we know and trust them, or we don't.

Looking in Jira, Michael's track record looks very good to me.

Doug

Thanks Doug for the vote of confidence and the well written response!

I think your reasoning (about not creating branch-only committers) makes
sense.

Mike

Doug Cutting wrote:
> Erik Hatcher wrote:
>> It's done frequently. In Lucene-land we have some committers that
>> only have rights to certain contrib sub-directories, for example. We
>> could easily do this for particular branches as well.
>
> We actually have a set of contributors who only have access to the
> entire contrib directory. This is for folks who primarily just maintain
> a contrib module. We could make things more fine-grained, but that gets
> messier to maintain.
>
> It's about trust and community. Committers are folks who are trusted by
> the community of other committers to make commits on their own. A
> committer doesn't have to master all portions of the repository that
> they *can* modify, only those that they *do* modify. We trust
> committers not to modify things in areas where they're not fully
> competent. It's therefore in theory reasonable to have committers who,
> e.g., only maintain documentation or perform release management.
>
> Trust is typically earned by developing a track record of commit-quality
> patches. Each time a contributor says, "this patch is ready to commit"
> they create a point of evaluation for themselves. If the patch is
> committed with no modification, then they've earned credit towards
> becoming a committer. (Significant patches and patches to core
> components earn extra credit.) If other committers request some
> modifications to the patch, and the contributor makes those changes,
> then the committer is still learning what's expected. So, if you want
> to be committer you should be careful about what you indicate is ready
> for commit. That said, it's really not such a cold calculation. The
> community comes to know and trust a contributor based primarily on
> mailing list interactions, and the patch record merely provides assurances.
>
> This is a long-winded way of saying that I don't think we ought to add a
> committer for just a branch. If we trust someone sufficiently to let
> them commit to a branch that we intend to merge into the trunk,
> shouldn't we also trust them to not abuse the trunk? To some degree,
> either we know and trust them, or we don't.
>
> Looking in Jira, Michael's track record looks very good to me.
>
> Doug