[kepler-dev] impending beta release, cvs branch, and development process changes

Tue May 16 12:04:51 PDT 2006

Hi Matt,

Sounds good!

The Ptolemy II tree is in a pretty good state.  I've spent some time
cleaning up broken links and demo problems.  Now is as good a time as
any to have taken the snapshot.

For my part, I'll be more careful about breaking the build.  One
problem is that rebuilding Kepler takes time, so I've only been doing
it once or twice a day.  I'm now on the Nightly Build email 
(http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-nightly)
I added a link to the developer's page for the nightly build and
the current Kepler Bugs.

I'd like to refactor the DocViewer, but that can wait.
I'd still like to look at removing the duplicate
classes having to do with the DocViewer in Kepler.

Is the doccheck output available?  It might help to have people clean
up code?  Also, are there any code coverage stats available?
Maybe there needs to be a standdown where everyone cleans code,
writes tests and reviews code for a few days?  Just an idea, I'm not
sure it is at all practical.

I think this is probably the dark before the storm.  Of course, then
again, sometimes the light at the end of the tunnel is an oncoming
train. :-)

_Christopher

--------

    Our current roadmap calls for a beta1 release on April 28, which we 
    missed (again).  This necessitates delaying the 1.0 release again, as 
    its unrealistic to commit to the current code base for a production 
    release.  Stabilizing the code has been difficult, so it is 
    understandable, but some of it is a matter of getting the right people 
    focused on the task.  I am hopeful that we'll be able to buckle down and 
    focus over the next few months and get the release out.  Towards that 
    end we came up with some suggestions during a meeting of the SEEK 
    project the week before last.  The following proposals are from the SEEK 
    developers.

    We propose the following revised schedule:
       Beta 1: stabilize current features, 'preview' of 1.0
               I created a cvs branch for the release (KEPLER_1_0_0_BRANCH),
               new work will need to be checked into the HEAD and the
               branch if it is stable enough.  New features targeted for
               the branch should be discussed before checkin.  I tagged the
               ptII module at its current spot because it seems to be working
               with Kepler (KEPLER_1_0_0_MARKER), so we should be able to
               return to this spot in the ptII tree as needed.
               Freeze checkins for the beta on Friday, May 19 (this week!).
               Dan Higgins will build release on Monday, May 22.
               Will release on web later next week after testing.

        1.0.0: Aim for middle of this summer.  We identified a list
               of features that are still outstanding.  We also identified
               a number of bugs and stability problems.  We feel that an
               adequate testing regime is critical, and is not yet in
               place for a variety of reasons (see below).
               Freeze date for 1.0.0 to be determined during a
               Kepler conf call.

    We feel that many of the issues that have plagued the project are due to 
    a lack of formal structure and requirements in the development process. 
      Our general assessment was that the quality of the code could be 
    tremendously improved by requiring more of an emphasis on requirements 
    and design before coding, by requiring that developers write complete 
    tests that cover all public interfaces for classes before writing code, 
    and that all code that is checked into CVS be reviewed by another Kepler 
    project member before committing.  As a consequence, we propose the 
    following process changes to the Kepler development process:

    1) We will shift to a continuous integration build instead of a nightly 
    build.  Builds will be conducted on multiple platforms (Win/Mac/Linux) 
    in continuous fashion (ala Tinderbox).  Each time a build is run, the 
    tests for that build will be run too.  Web reports will show any broken 
    builds or failed tests, and will list the people who have committed code 
    since the previous successful build.  Those people will be responsible 
    for fixing any problems.  Any person who repeatedly breaks the build 
    will be reviewed by the project members and their write privileges will 
    be revoked if the members deem it necessary for project stability.

    2) The CVS system will be modified to perform additional checks upon 
    commit.  Whenever code is committed, the system will check to see if a 
    test exists for that class.  If not, the commit will be rejected by the 
    system.  Developers are strongly encouraged to write tests with complete 
    coverage for their classes, althogh we recognize that this is at times 
    impossible (e.g., for GUI classes) and therefore can not be strictly 
    required.  In addition to testing the public methods, each actor non-gui 
    class should have a test workflow that exercises its functionality and 
    verifies that its output is correct.  The CVS system will also check 
    that all methods have javadoc comments and reject any classes that are 
    undocumented.  Simply putting in placeholder documentation is 
    unacceptable, but as we have no way to automate quality assurance in the 
    documentation, the system will only check if Javadocs are present.  If 
    absent, the commit will be rejected.

    3) Developers are strongly encouraged to have another Kepler developer 
    review either the classes or tests for consistency with design goals, 
    quality of the implementation and documentation, and coverage of the 
    tests.

    4) Many stability problems in Kepler are due to the tight relatinship 
    beween the core system and the individual actors.  We propose to 
    separate the build for core Kepler and the actors so that it is clear 
    which source code and libraries are needed for the system and which are 
    only needed for actors.  The build will be revised to make it more 
    robust to failures in the actor tree, both at compile time and at 
    runtime.  Additions to the jar file list for core Kepler should be 
    discussed on the mailing list prior to committing.  Any additions of new 
    jars should be examined for conflicting classes/duplication with 
    existing jars, and only committed if no such problems exist.  When 
    duplications would be found, the kepler-dev mailing list should be 
    consulted to determine which version of the libraries should stay in the 
    build.  Any developer changing the version of a library (e.g., Xerces) 
    is responsible to be sure that all refactoring of code needed is done 
    and that all tests are still passed after the changes.

    We think these changes will help with our long term stability by simply 
    focusing more effort on testing and documentation.  Matthew Brooke is 
    working on implementing some of these changes in a new, more robust 
    nightly build system.  I will be working on making the CVS changes.  We 
    would appreciate any comments or additional suggestions to this 
    proposal.  Thanks.

    Matt
    -- 
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Matt Jones                                   Ph: 907-789-0496
    jones at nceas.ucsb.edu                    SIP #: 1-747-626-7082
    National Center for Ecological Analysis and Synthesis (NCEAS)
    UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------