Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
In-Reply-To: <Pine.LNX.4.58.0507051856100.18194@saturn.opentools.org>
To: dev@geronimo.apache.org
Subject: Re: Project Dependencies: TranQL & maybe someday GBean.org
MIME-Version: 1.0
From: sissonj@insession.com
Message-ID: 
 <OF75BED421.65C10882-ONCA257035.00831375-CA257036.000750B1@tsainc.com>
Date: Wed, 6 Jul 2005 12:19:52 +1100
Content-Type: text/plain; charset="US-ASCII"

I was just thinking about the issues of external project dependencies in 
general.. Should there be a process for evaluating the introduction of new 
'critical' dependencies in Geronimo. 

I think we should at least ensure that a 'critical' external project meets 
a minimum criteria, for example:

* An operational web site and documentation that describes the dependency 
(more than just a paragraph).
* Operational mailing lists and mail archives
* Operational bug tracking system
* More than one Geronimo committer on the project

Currently some of the projects being discussed in this thread do not meet 
the 'example' criteria above.  Just picture yourself as a new Geronimo 
developer wanting to get involved.  Go to these project websites and try 
looking at the mailing list archives and see how much information you can 
find about the project.

What would be the impact to the Geronimo community if a critical project 
initially met this criterial then stops meeting the 'example' criteria?

Have we identified the risks of depending on 'critical' external projects. 
 I'm not saying we shouldn't rely upon them, but at least think about the 
risks and how they can be minimised.  For example is it safe to rely upon 
these assumptions?:

* that the project host will always be operating
* that the project host will backup the project source (mistakes can 
happen) and that we will always have access to the source.
* that mailing list archives for the project kept by the hosting project 
will always be available.
* that the bug tracking records for the project will always be available

If Geronimo is integrating best of breed external components, then IMHO, 
the project infrastructure and community around those components should be 
well established.

John

This e-mail message and any attachments may contain confidential, 
proprietary or non-public information.  This information is intended 
solely for the designated recipient(s).  If an addressing or transmission 
error has misdirected this e-mail, please notify the sender immediately 
and destroy this e-mail.  Any review, dissemination, use or reliance upon 
this information by unintended recipients is prohibited.  Any opinions 
expressed in this e-mail are those of the author personally.

Aaron Mulder <ammulder@alumni.princeton.edu> wrote on 06/07/2005 09:08:13 
AM:

>    Changing the subject since we're drifting again.  This is related
> to another issue that's come up off-list, but we may as well open it to 
a
> broader discussion here.
> 
> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
> > TranQL is a Codehaus project so it is down to the despots, currently 
me. 
> > The barrier to entry is not high but so far I've not seen anything 
> > except that problematic patch.
> 
>    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).
> 
>    Jeremy, would you consider either substantially enlarging the 
> community of despots for TranQL, bringing it to Apache, or merging 
> it into OpenEJB?
> 
>    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)?
> 
> Thanks,
>    Aaron