Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 45206 invoked from network); 12 Jul 2005 21:39:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Jul 2005 21:39:01 -0000 Received: (qmail 83371 invoked by uid 500); 12 Jul 2005 21:38:55 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 83251 invoked by uid 500); 12 Jul 2005 21:38:54 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 83203 invoked by uid 99); 12 Jul 2005 21:38:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jul 2005 14:38:54 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jgenender@savoirtech.com designates 209.181.65.237 as permitted sender) Received: from [209.181.65.237] (HELO sun.savoirtech.com) (209.181.65.237) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 12 Jul 2005 14:38:51 -0700 Received: from [192.168.0.4] ([10.197.197.5]) by sun.savoirtech.com (8.12.11/8.12.11) with ESMTP id j6CLck6F006364 for ; Tue, 12 Jul 2005 15:38:48 -0600 Message-ID: <42D43865.6020601@savoirtech.com> Date: Tue, 12 Jul 2005 15:38:45 -0600 From: Jeff Genender User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: Donations & Policies References: <20050712163558.61923.qmail@web32601.mail.mud.yahoo.com> <03a3768d99664dcf529274d40ccf962a@yahoo.com> <20050712184130.GA27991@django> In-Reply-To: <20050712184130.GA27991@django> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on sun.savoirtech.com X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on sun.savoirtech.com X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-149.2 required=5.6 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.3 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I have been waffling a bit back and forth on this issue...but I think I have come to terms on my thinking on this subject. I am not sure a "concrete" policy is necessary. Every piece of code that comes through as a donation, either from a commercial vendor or from another open source project or community will have different manners in which they come through the door. Some may approch the PMC first. Some may just announce the desire on the the lists. Each on will be different. How we handle each of these projects will likely not be the same niether. Some may flourish as a sub project to stand on thier own, some are good for just being Geronimo specific. A good example is the console vs Trifork. Clearly one can live on its own where the other cannot. Perhaps "guidelines" or a howto, that offers options on how to get your code into the project as a opposed to a "policy'. Ultimately, IMHO, each will be individually handled based on the merits and direction of the code base coming in, as well as any additional baggage that comes along with it. David Blevins wrote: > ("superb support and mentoring for our new members and left the > questions of what to do if we fail to such time as it might be > needed.") > > +1 Building relationships, mentoring, thousand points of light. > > > Respectfully, > David > > > On Tue, Jul 12, 2005 at 10:32:48AM -0700, David Jencks wrote: > >>In order to avoid mile-long emails I'm starting over. >> >>I think our overall goal is to strengthen the geronimo community by >>bringing in new developers and code that we as well as they want to >>work on. >> >>This process is likely to be more work for us than the new developers, >>since they already know their code very well, whereas we need to learn >>their code and more importantly mentor them into being part of the >>geronimo community. Therefore, we need to put together a process that >>involves the least work for us, and we need to commit the time needed >>to be good mentors. To me, this means that the new people need to be >>given commit access to at least their donated code, since we simply >>won't have time to review all the patches that are likely to result >>otherwise, and the svn structure needs to be set up for minimal >>nuisance/simplest builds. I think the last would be best with the new >>code going somewhere in the geronimo/trunk tree: although svn tricks >>are certainly possible to pull it in from elsewhere in apache svn, this >>would add some complexity for no gain I can see. >> >>I also think it is important to publish a process for donations, so we >>don't spend weeks discussing this every time someone offers something, >>and so potential donors know what to expect and dont get the idea that >>we are playing favorites. If we run into problems, we can certainly >>update the process. >> >>I'd like to reemphasize that bringing in new committers with their code >>is going to be a lot of work for the existing community. If we fail to >>integrate a donation a very large part of the responsibility rests with >>us for not having good enough community skills to work with the >>newcomers. It seems to me that discussions about limited commit >>access/ acls/ etc are fundamentally discussions about what happens if >>we fail. I wonder what would happen if we instead discussed how we >>will provide superb support and mentoring for our new members and left >>the questions of what to do if we fail to such time as it might be >>needed. >> >>thanks >>david jencks