[kepler-dev] an introduction and some questions

Tue Apr 5 10:38:41 PDT 2005

My 2 cents...

Bertram Ludaescher wrote:
> 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.
Sure -- ptolemy's configuraiton mechanism can be used.  This means 
checking in a new configuration directory into the kepler CVS with your 
configuration files. For example, you could create a configuration that 
used a different set of actor annotations to choose which actors to 
display and how to categorize them.  The configuration directories are a 
little weird, but basically you need to make a copy of one of the 
existing configuration directories (which are located 
"kepler/configs/ptolemy/configs").  Then you start kepler using a switch 
that indicates it should use your configuration.  You should sign onto 
IRC if you want more information about this.

> 
> 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!)
Developers are supposed to write unit and regression tests for all of 
their code that they check in, as well as test workflows that exercise 
their actors.  The test workflows act as a whole system test.  Unit and 
regression tests are stored under the kepler/tests directory hierarchy, 
and test workflows are stored under the "workflows/tests" directory. 
Each test workflow that you want run as part of the nightly build also 
must be listed in the file "lib/test-workflows.lst".  The build is done 
automatically every night, and results are emailed to the members of the 
"kepler-nightly" mailing list.  You can subscribe here:

http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-nightly

You can also see nightly build results here:
   http://www.kepler-project.org/nightly/

> 
> 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.
Contributors maintain their own files to a degree.  We do however want 
this to be an integrated project, so we are moving towards a functional 
classification of actors and classes rather than a project-based one. 
The src/kepler subtree has these more generic classes, and most of the 
other subtrees are fairly generic.

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

We agreed early on to use a BSD-style license for all of our files, and 
we agreed on the form of that file.  We also agreed that individual 
authors/institutions should maintain copyright for the files that they 
contribute.  At this point, most contributors have been from a UC 
campus, and they all have the same copyright statement.  You should feel 
free to change the name of the copyright holder in the statement to your 
institution for the things you write.  The example copyright statement 
that you should include in your file is "kepler/copyright.txt".  When we 
first started Kepler we used a GPL license, but we decided to drop that 
in favor of the BSD license.  Any files that you find with a GPL license 
statement in them need to be updated with the BSD license and are just 
oversights.

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

Looking forward to interactions with you.

Matt

> 
> 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
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------