From open-jpa-dev-return-37-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Mon May 15 20:30:12 2006 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 84472 invoked from network); 15 May 2006 20:30:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 May 2006 20:30:11 -0000 Received: (qmail 36323 invoked by uid 500); 15 May 2006 20:30:11 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 36283 invoked by uid 500); 15 May 2006 20:30:11 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 36272 invoked by uid 99); 15 May 2006 20:30:11 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 May 2006 13:30:11 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of robertburrelldonkin@gmail.com designates 64.233.184.227 as permitted sender) Received: from [64.233.184.227] (HELO wr-out-0506.google.com) (64.233.184.227) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 May 2006 13:30:10 -0700 Received: by wr-out-0506.google.com with SMTP id 68so863059wri for ; Mon, 15 May 2006 13:29:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=K+DJf2UASpSu+8QtB/diMNswkj/F8MwH2hZLxt8B7+uX1w7lDkRgwlwRx8Hse3rwq90jQhxlXhAr2/uo1MRiHsfKIaocqpTp9tQZ2yI8kovZsdfnH4HRkOVZ25nFcpAkKwrzK+NO86QObvp8BCNZLctSXhew7qmxDzqaeVH0fEU= Received: by 10.65.22.16 with SMTP id z16mr1564513qbi; Mon, 15 May 2006 13:29:49 -0700 (PDT) Received: by 10.65.253.4 with HTTP; Mon, 15 May 2006 13:29:49 -0700 (PDT) Message-ID: Date: Mon, 15 May 2006 21:29:49 +0100 From: "robert burrell donkin" To: open-jpa-dev@incubator.apache.org Subject: Re: Access to Open JPA In-Reply-To: <7D856CDFE035FF45A0420ACBD71BDD630115A733@repbex02.amer.bea.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_37818_30359282.1147724989681" References: <7D856CDFE035FF45A0420ACBD71BDD630115A733@repbex02.amer.bea.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_37818_30359282.1147724989681 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 5/15/06, Patrick Linskey wrote: > > Guys, > > I'd kinda like to keep things as locked-down as possible until we're > closer to having functional code. So I'd rather just get people actually > committing now who are looking at build environment set-up etc., so that > we can minimize the number of moving parts. Does that sound reasonable? (some tangental ramblings on open development...) the primary method of oversight in ASF projects is by reading commit records. this is something that podlings need to get used to. commits are approved by lazy consensus: any commit can be -1'd (if there is sufficient reason) and reverted. this may force a vote. note that this should happen rarely in a healthy community. it's more polite to point out mistakes without a veto. social conventions are powerful. most people don't like looking stupid in public. access control at the ASF is necessary for some extra security in depth in the event of a compromise and to give privacy for confidential information (for example, security). podlings begin in a slightly atypical state. the typical apache contributor starts by submitting patches. these patches are reviewed and committed by existing committers. it is rare for the initial contributions of a develope= r new to a project to be committed without changes. gradually, if the developer learns from the feedback the patches should need fewer and fewer changes. this builds trust and confidence until the developer is elected a committer. at which stage, the review happens after the commit. - robert ------=_Part_37818_30359282.1147724989681--