From general-return-390-apmail-lucene-general-archive=lucene.apache.org@lucene.apache.org Fri Nov 03 18:06:12 2006
Return-Path:
Delivered-To: apmail-lucene-general-archive@www.apache.org
Received: (qmail 92559 invoked from network); 3 Nov 2006 18:06:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 3 Nov 2006 18:06:11 -0000
Received: (qmail 91729 invoked by uid 500); 3 Nov 2006 18:06:21 -0000
Delivered-To: apmail-lucene-general-archive@lucene.apache.org
Received: (qmail 91712 invoked by uid 500); 3 Nov 2006 18:06:21 -0000
Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: general@lucene.apache.org
Delivered-To: mailing list general@lucene.apache.org
Received: (qmail 91700 invoked by uid 99); 3 Nov 2006 18:06:21 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Nov 2006 10:06:21 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [204.127.192.83] (HELO rwcrmhc13.comcast.net) (204.127.192.83)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Nov 2006 10:06:05 -0800
Received: from [192.168.168.15] (c-71-202-24-246.hsd1.ca.comcast.net[71.202.24.246])
by comcast.net (rwcrmhc13) with ESMTP
id <20061103180544m1300o2ij9e>; Fri, 3 Nov 2006 18:05:44 +0000
Message-ID: <454B84F7.10003@apache.org>
Date: Fri, 03 Nov 2006 10:05:43 -0800
From: Doug Cutting
User-Agent: Thunderbird 1.5.0.7 (X11/20060922)
MIME-Version: 1.0
To: general@lucene.apache.org
Subject: Re: non-committers & branches in SVN
References: <454A1D13.3030106@mikemccandless.com> <70D658E6-B187-419D-96D2-30EA407AB36D@ehatchersolutions.com> <454B1974.20007@mikemccandless.com> <1C227FB1-2D3B-4097-BCC1-A12280A315BD@ehatchersolutions.com>
In-Reply-To: <1C227FB1-2D3B-4097-BCC1-A12280A315BD@ehatchersolutions.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
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