--- Phil Steitz <[EMAIL PROTECTED]> wrote:
> On 6/3/05, robert burrell donkin <[EMAIL PROTECTED]>
> wrote:
> > On Thu, 2005-06-02 at 22:58 -0700, Al Chou wrote:
[deletia]
> I think the modified scope specified later in this thread is in scope
> for j-c-m. I agree that the scope of the initial proposal goes beyond
> j-c-m, or j-c or even Jakarta (the C# port).
>
> I like the idea of using the more modest extensions here to build
> community, then maybe play a bit over the boundaries - including even
> C# - in the sandbox and then think about incubating apache math.
+1
> It is nice to see our original apache sponsor still willing to help
> move us along :-)
Agreed!
> For the moment, however, I think it is best to propose this as an
> extension to j-c-m.
+1
> > IMHO one of the first jobs of the mentors will need to do will be to
> > study the proposal and create a realistic core tasks together with a
> > more ambitious list of additional tasks. (this should ensure that ryan
> > is not unfairly financially penalised for his ambition.) it's hard to
> > estimate a priori what the quality and quantity of any code produced by
> > ryan will be but i agree that the code will need to satisfy the current
> > standards especially in the area of development best practice. the
> > mentors will need to work with ryan to ensure that he knows what's
> > expected particular when it comes to using code developed by others.
> >
> Agreed. That is what I am signing up for. Fortunately, the current
> code base, the developer guide and various other apache docs give good
> guidance on code and IP requirements. I will follow up with the SoC
> organizers on the whole issue of managing scope and deliverables (in
> some ways antithetical the apache way) because I agree that this could
> be onerous and we want to ensure that
> 1. Ryan and any other students who participate have a clear
> understanding of what is expected and how much they are signing up for
> 2. The quality of what is committed meets the standards of j-c-m
> 3. We do not introduce any IP issues
Great!
> > > Also, specifically what parts of the proposal are not already addressed
> by
> > > existing libraries such as Colt? I thought we were over the licensing
> hurdle
> > > for Colt, so anything it already does probably should not be duplicated
> by code
> > > newly written for the proposed project.
>
> This may not be a consensus or popular view, but even if/when we
> eventually become apache math, I will be opposed to "annexing code"
> without community. So, regarding Colt in particular, if the Colt
> community decides to join us at some point and wants to do a software
> grant, go through the incubator, etc., that will be great. Until such
> time, I think it is fine for us to "duplicate functionality" with
> j-c-m APIs and j-c-m volunteers for things that fit within our scope.
> What is essential to me is that we have developers actively supporting
> all code that comes in. Anything that we commit, we need to be able
> to support.
Phil, that's an interesting point, which I hadn't considered. Here's an
off-the-cuff counterproposal: let us annex the parts of Colt that we need,
when we need them, if that seems the right thing to do for the particular need
at the time. That way we will ensure community exists (our own) for the code
that is imported.
Al
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
