lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: non-committers & branches in SVN
Date Fri, 03 Nov 2006 18:05:43 GMT
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

Mime
View raw message