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
