> -----Original Message----- > From: Mark R. Diggory [mailto:[EMAIL PROTECTED] > Sent: Monday, September 08, 2003 11:42 AM > To: Jakarta Commons Developers List > Subject: [math] Project Maturity? > > > I think we should discuss what really needs to get completed for the 1.0 > release of math. I think there are three points of interest. > > A.) If it isn't a major refactoring, it probably stands that we can > provide a feature in a later minor release, for example, "adding > confidence intervals", extending distributions with discrete capabilities.
Agreed. With the hypergeometric patch, all the distributions promised for the first release have been delivered. > > B.) Many tasks are "ongoing" and are never "really" finished, ie > accuracy testing, checkstyle and javadoc. Again I agree. With my latest javadoc patch, checkstyle violations were down to under 20 and javadoc warnings under 50. This I believe is acceptable since other commons projects have checkstyle errors numbering in the thousands. > > C.) Many aspects of the project already out-perform even that which is > in commons proper. Documentation and JUnit testing is fairly thorough. The only thing I would like to see (but it doesn't have to happen before a release) is the expanding of the user guide. > > So I wonder, would it be logical to request a vote from the community > proper to consider that maturity of the math project and if its ready to > release a version? There will always be discovered issues. But we do > need to get to the point where we have actual users to discover those > issues. > > -Mark Diggory > I have no problem with having a vote. > > > Here's a list of the tasks from the current task list: > > 1.) Develop user's guide following the package structure. > Provide any comments on this task here. This would be the only thing, at this time, I think we should work on prior to a vote. However, since the javadoc is quit complete, not having this done should not impact any vote outcome by much. > > 2.) Performance and accuracy testing. > If anyone is interested in helping out here, what we could really > use is a wider selection of test cases for the core numerical functions > and validation against either other packages (e.g. R for the statistical > stuff), verified datasets, or experiments comparing implement ions using > floats to doubles. > > 3.) Test Coverage. > Clover tests show gaps in test path coverage. Get all tests to 100% > coverage. Also improve test data and boundary conditions coverage. FYI, 100% coverage is impossible with our design decisions. There are private, default constructors that never get called and are not intended to get called. As such, the methods can never be covered during test execution. With my test-coverage patch, I got just over 90% coverage. There were a couple of classes with individual coverage of <50% which, if test were written, could boost the coverage closer to 95%. In short, I think our unit test are more than adequate and we should change the 100% notion on the site to something realistic like 90% or 95%. Brent Worden http://www.brent.worden.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
