Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 58236 invoked from network); 6 Jul 2005 09:49:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jul 2005 09:49:04 -0000 Received: (qmail 28534 invoked by uid 500); 6 Jul 2005 09:48:54 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 28267 invoked by uid 500); 6 Jul 2005 09:48:52 -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 28254 invoked by uid 99); 6 Jul 2005 09:48:51 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2005 02:48:51 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [155.208.255.20] (HELO bbnrelbul01.net.external.hp.com) (155.208.255.20) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2005 02:48:51 -0700 Received: from vistula.poland.hp.com (vistula.poland.hp.com [15.188.0.12]) by bbnrelbul01.net.external.hp.com (Postfix) with ESMTP id 461C638D05 for ; Wed, 6 Jul 2005 11:48:46 +0200 (CEST) Received: from [127.0.0.1] ([16.19.170.65]) by vistula.poland.hp.com with SMTP (8.9.3 (PHNE_28760_binary)/8.8.6 SMKit7.02) id LAA25123 for ; Wed, 6 Jul 2005 11:48:38 +0200 (METDST) Message-ID: <42CBA8E3.3010906@apache.org> Date: Wed, 06 Jul 2005 11:48:19 +0200 From: Jacek Laskowski Organization: Apache Geronimo (http://geronimo.apache.org) User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: Project Dependencies: TranQL & maybe someday GBean.org References: <20050704212155.GD18287@django> <42C9D2CC.80306@apache.org> <20050705012722.GA18701@django> <42C9E48F.30803@apache.org> <20050705021534.GA18755@django> <20050705024643.GC18794@django> <42C9FF8A.70008@apache.org> <42CAB15D.5020308@apache.org> <42CB0ABF.6050507@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Aaron Mulder wrote: > Okay. Well, without getting into specifics, I'm not real > comfortable with Geronimo being heavily dependent on a Codehaus project > with precisely one, er, despot. I feel the same about the GBean.org > kernel, which while not currently a part of Geronimo, will likely be a > candidate for it (and this of course is one of the issues around it). It was *our* decision to rely on these projects. I agree we need to be very careful about what they are in the future, but I don't think it's a problem with TranQL at the moment. Although we could have considered TranQL as a problem having seen some troubles recently, I'm sure we will be able to work them out easily. > Jeremy, would you consider either substantially enlarging the > community of despots for TranQL, bringing it to Apache, or merging > it into OpenEJB? Do you think that committers behind selected projects would change their rules to grant commit access only because Geronimo decides to rely on their work? I don't think so and would be very surprised if they did. Our approach to work with other projects should be to be in touch with these projects and the time will show if we earn their appreciation which would finally result in the commit access. I remember someone said the commit access should be seen as an acknowledgement of someone's contribution rather than what project (s)he represents. I completely second that point. > Dain, would you consider either substantially enlarging the > community of despots for GBean.org, bringing it to Apache, or merging it > into Geronimo (as a branch or sandbox module for the present, I presume)? In case of the GBean project, it's much better since we don't yet rely on them as much as we do on TranQL. It's still under discussion whether it is the way to go or we will reinvent the wheel or come up with a better alternative. > Aaron Jacek