+1 I think you better stated what I was trying to get at. Aaron
On Wed, 6 Jul 2005 [EMAIL PROTECTED] wrote: > 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 <[EMAIL PROTECTED]> 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 > >
