lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: non-committers & branches in SVN
Date Fri, 03 Nov 2006 18:33:56 GMT

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


Mime
View raw message