lucene at mikemccandless
Nov 3, 2006, 10:33 AM
Post #6 of 6
Thanks Doug for the vote of confidence and the well written response!
I think your reasoning (about not creating branch-only committers) makes
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.