[kepler-dev] impending beta release, cvs branch, and development process changes
Ilkay Altintas
altintas at sdsc.edu
Mon May 22 11:10:00 PDT 2006
Hi Matt,
Apologies for the delay in responding. Better late than never... :)
We discussed the suggestion last week with some at SDSC and agree
with most of the suggestions. Some specific comments are interspersed
below.
On May 16, 2006, at 11:43 AM, Matt Jones wrote:
> 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.
This is good. We checked in the documentation and tests throughout
last week.
> 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.
This sounds reasonable. I suggest having conference calls every other
week after the beta (today) to coordinate the release status.
>
> 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.
This is a bit arguable. It might make some developers hold back from
checking in useful code. I don't have a better suggestion right now.
How do we decide it is a misdemeanor or a felony. :) Maybe we can
make "serial build breakers" :) consult with a few developers before
they check in code instead. And make the changes gradually instead of
waiting for a long time before checking in code.
>
> 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.
This is a great suggestion.
>
> 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.
I think this should be a standard. Maybe we can come up with a couple
of questions for the developers to go over when reviewing each other
code.
We recently have started doing code reviews at SDSC. It is very
useful. We can try to come up with a small set of questions fro
check-in reviews.
> 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.
Could we discuss this over a conference call with all the interested
developers? How about sometime this week? Thursday maybe?
> 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.
Thanks for going over these very important issues!
Cheers,
-ilkay
>
> 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
=============================================================
Ilkay ALTINTAS
Assistant Director, National Laboratory for Advanced Data Research
(NLADR)
Manager, Scientific Workflow Automation Technologies (SWAT) Lab
=============================================================
San Diego Supercomputer Center(SDSC), UCSD
9500 Gilman Drive, MC: 0505 La Jolla, CA 92093-0505
phone: (858) 822-5453 fax: (858) 822-3693
web: http;//users.sdsc.edu/~altintas
=============================================================
More information about the Kepler-dev
mailing list