geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Project Dependencies: TranQL & maybe someday GBean.org
Date Wed, 06 Jul 2005 02:56:06 GMT
+10000

I think David nailed it.  The Geronimo project should be really  
careful when depending on projects that are not vibrant projects that  
stand on their own (without geronimo involvement).  It is clear that  
neither GBean or TranQL are projects that stand on their own right now.

As for GBean, I can say that we, the GBean project, are actively  
working on all of the criteria that you list, and we are working on  
getting the kernel used by other projects (which should help to  
spread out the risk).

-dain

On Jul 5, 2005, at 7:29 PM, sissonj@insession.com wrote:

> I agree that in the case of cglib it is unrealistic, since AFAIK  
> none of
> their committers are involved in the Geronimo project and as you  
> said it
> is a stable project.
>
> IMHO it would be realistic for the TranQL and GBean.org projects as  
> the
> developers on those projects have been involved in the Geronimo  
> project
> and I would hope they would be willing to spread their knowledge  
> and get
> others in the Geronimo project involved for the best of both  
> Geronimo and
> those 'evolving' external projects.
>
> It is probably hard to set a criteria in stone for when it does makes
> sense.
>
> Thanks,
>
> John
>
> David Jencks <djencks@gluecode.com> wrote on 06/07/2005 11:32:03 AM:
>
>
>> While I'm sympathetic to your goal here, the committer requirement is
>> unrealistic in general.  I don't think it too likely that any of us
>> will become cglib committers in the near future, but it is a stable
>> project with plenty of other users.
>>
>> thanks
>> david jencks
>>
>> On Jul 5, 2005, at 6:19 PM, sissonj@insession.com 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 <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
>>>>
>>>
>>>
>>
>


Mime
View raw message