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

Matt Jones jones at nceas.ucsb.edu
Tue May 16 11:43:31 PDT 2006


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


More information about the Kepler-dev mailing list