[kepler-dev] an introduction and some questions

[Bertram Ludaescher]

Dear Tim:

Thanks for your great questions. But first: did you get r/w access to
the cvs repository already? If not, let me know.

See below for more comments ...

Timothy McPhillips writes:
...
 > 1.  Would it be OK to create a Kepler software release customized for 
 > NDDP users?  (I mean direct users of the "phylogenetics workflow 
 > automation framework," not those using the web-based "discovery 
 > environment"--see the NDDP web page).  The variety of actors in Kepler 
 > and Ptolemy II is rather dizzying.  I'd like to keep things simple for 
 > my users (and keep the software distribution reasonably sized).

Good point. I don't see a problem with creating a customized
release. Dan Higgins from Kepler/SEEK has be dealing with the main
Kepler releases in the past and I'm sure he'd be able to help you with
the process. Also Ilkay and Xiaowen (from Kepler/SPA) have done custom
releases and should be able to help.

There are a number of ways to do this (you can used this forum, or the
Kepler-IRC or the Kepler wiki page for follow ups/additional info,
respectively) 

 > 2.  Are there procedures for determining and documenting the stability 
 > and quality of code, e.g., something like the Ptolemy project's code 
 > rating system?  

Good point. I think the original idea was to adopt Ptolemy's system
(or at least the general coding rules/style, possibly with minor
variations). There are also plans for the first more thoroughly tested
beta release (due very soon now AFAIR!)

I'll let other chime in on the detailed plans.

 > And are specific people or groups responsible for 
 > maintaining particular sub-projects or source files?  I'd like to have 
 > some way of knowing that only stable, tested code makes it into NDDP 
 > software releases. And it would be nice to know who to turn to if a 
 > problem arises.

Another good point. At some point there was an idea to structure
contributions (primarily actors) simply be adding files to
project-specific directories. However, several of the members from
different projects work on very closely related stuff, so that the one
directory = one project idea doesn't work that well.

Instead, authors are identified on a per-file (approx. per actor) basis. 
The basic idea is: don't break the build (and the tests ... more on
that is coming) when checking in new stuff.

Again, kepler-IRC and kepler-dev should be good ways to get problems
sorted out.

 > 3.  Are there any policies (or strong feelings) on intellectual 
 > property and software licensing?  I see many Kepler source files that 
 > are copyrighted by the University of California and have a 

since many of the contrib. members are UC members (Berkeley, San Diego, Santa
Barbara, and in the future we'll see also stuff from Davis -- would be
nice to have one Kepler member from each UC campus ;-)

 > Berkeley-style license.  I also see a fair number of files with a GNU 
 > Public License.  I want to be able to distribute NDDP software freely 
 > (I've used an MIT-style license for past projects). I would like the 
 > NDDP to retain the copyright on the software I contribute.  And I would 
 > prefer to avoid dependencies on software with licenses more restrictive 
 > than the Berkeley license.  Does using a CVS repository at UCSB (?) 
 > have any implications in these regards?

hmm.. good questions. I'll pass on those however. 
License experts to the front!

 > Thanks very much for any help you can provide.  I know from experience 
 > that these kinds of organizational issues can be time-consuming to 
 > address.  Be assured that I very much admire the Kepler effort and hope 
 > that I can contribute to it.

I'm sure you will -- we're looking forward to it!

Bertram

 > 
 > Best regards,
 > 
 > Tim McPhillips
 > 
 > _______________________________________________
 > Kepler-dev mailing list
 > Kepler-dev at ecoinformatics.org
 > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev