commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math][all] Mentoring for Google's Summer of Code program
Date Sat, 04 Jun 2005 16:59:45 GMT
On 6/3/05, robert burrell donkin <> wrote:
> On Thu, 2005-06-02 at 22:58 -0700, Al Chou wrote:
> > Questions of scope of Commons-Math aside <gasp>, what is the scope of the
> > summer project?  The scope of Ryan's proposal seems mighty ambitious, even if
> > you remove the parts that aren't currently in scope for Commons-Math.
> i think that it would be useful to separate the question of scope from
> the question of mentoring and community.


> i definitely agree that the commons-math group is the right one for
> mentoring this code. i also agree (with simon) that jakarta commons is
> the best community for growing this code (whilst math remains here, of
> course).

> in terms of scope, IMHO there are two separate questions: is the
> proposed codebase in scope for the jakarta-commons and is it in scope
> for the commons-math component. opinions on these questions welcomed :)
> if the codebase is not in scope for jakarta-commons then i'd be willing
> to sponsor this as an incubator project (when it is ready). it could be
> developed in the sandbox until then.

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.

It is nice to see our original apache sponsor still willing to help
move us along :-)

For the moment, however, I think it is best to propose this as an
extension to j-c-m.
> > If you
> > intend to stay true to Apache's charter, the code will have to be developed
> > firsthand, not copied from any other source, unless the license of the source
> > is compatible or the author(s) are amenable to adding an Apache-compatible
> > alternative license to their code or changing over to an Apache-compatible
> > license.  Coding that much from scratch and providing JUnit tests will be a
> > heck of a lot of work (maybe a little onerous if you do TDD).  And forgive my
> > skepticism, but code developed for coursework is unlikely to be as bulletproof
> > as the proposal aims for.
> it does sound ambitious (but there's nothing wrong with that)

> 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

> > 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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message