commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [math] JAMA update and options
Date Sun, 06 Mar 2005 14:54:12 GMT
Kim,

See <http://www.apache.org/foundation/how-it-works.html#incubator> and
<http://incubator.apache.org/> for a background on the apache incubator.

As Brian B likes to point out, we have *two* things to think about when 
it comes to incorporating code from / working with other communities:
1) doing the right legal thing
2) doing the right thing

It could be that we can *legally* pull in the entire JAMA code base 
without any involvement or support from the JAMA developers, but I at 
least don't think that would satisfy 2).  I think that would be bad for 
both JAMA and us. Are we ready to support all of that code? We need to 
build community as well as code here and I think it would be much better 
to either get the code + community from JAMA to join us or to follow one 
of the other options that I presented below (jar dependency or limited 
inclusion with mutual back-porting).

Phil

Kim van der Linde wrote:
> Ok, what the hell is an incubater project. I have integrated the 
> different decompositions already to the RealMatrix and they work fine.
> 
> So, just go ahead I would say.
> 
> kim
> 
> Mark Diggory wrote:
> 
>> Even if we have to go through the incubator, I'm convinced that adding 
>> the JAMA codebase into the math library is the best option. IMHO, I'm 
>> convinced that while the JAMA folks were very generous and open to 
>> providing the codebase to the public domain, that further enhancing 
>> its capabilities and providing any user support is not really in their 
>> interest. It would be far more in our interest if we forked the 
>> codebase and supported it. Any suggestion that the "JAMA folks" would 
>> have to "agree" to this is not the nature of public domain, IMO reuse 
>> of public domain doesn't require any such acknowledgment, though we 
>> should liberally acknowledge their contribution wherever possible.
>>
>> http://www.google.com/search?hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&oi=defmore&q=define:public+domain

>>
>>
>> http://math.nist.gov/javanumerics/jama/
>>
>>> *Copyright Notice* /This software is a cooperative product of The 
>>> MathWorks and the National Institute of Standards and Technology 
>>> (NIST) which has been released to the public domain. Neither The 
>>> MathWorks nor NIST assumes any responsibility whatsoever for its use 
>>> by other parties, and makes no guarantees, expressed or implied, 
>>> about its quality, reliability, or any other characteristic./
>>>
>> Note, JAMA is not a large codebase, and is in the public domain. As 
>> such, does this really require the need for an "Incubator project"?
>>
>> Thanks Phil for taking such an initiative.
>>
>> My $0.02,
>> -Mark
>>
>> Phil Steitz wrote:
>>
>>> I have gone back and forth a few times with one of the JAMA 
>>> developers at NIST (Bruce Miller) and legal-discuss and have finally 
>>> asked the ASF board for a ruling on whether or not we can start 
>>> pulling in some JAMA code. I wanted to start with the QR class, so we 
>>> can use that to get multiple regression implemented with decent 
>>> numerics.
>>>
>>> Before we start down this path, though I want to present some logical 
>>> alternatives and get others' reactions to them.  Rather than pulling 
>>> in bits of implementation code, we could
>>>
>>> 1) Introduce a jar dependency on JAMA and wrap / extend / directly 
>>> use the stuff we need.  For the QR use case, there will be no 
>>> performance / efficiency hit from this. For some of the other 
>>> RealMatrix uses, this might be tricky.
>>>
>>> 2) Bring in the full code base.  This would probably result in a side 
>>> trip through the incubator and might provide the occasion to get us 
>>> kicked out of commons (I am sure there are some who will be happy to 
>>> see us go :-) but that might be a good thing.  I don't know yet if 
>>> the JAMA guys would go for this, am interested in opinions of others 
>>> here.
>>>
>>> If I get the go ahead from the board, we will need to decide between
>>>
>>> 0) fork selected stuff into [math] and pass bug fixes back and forth 
>>> with JAMA
>>>
>>> and 1) or 2).  WDYT?
>>>
>>> Note that the same considerations apply to RngPack.
>>>
>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message