On 08/23/10 04:20 PM, kcrisman wrote:
Well, in general it seems to me that most Sage bugs come from things/
functionality that didn't exist before, and once they exist people
want to start using them.
Well, there are an alful lot of open-bugs in trac. Some have been open a very
long time. They are assigned to person X (for example I get the Solaris ones),
but person X does not work on them, but spends time writing new code.
But unlike a commercial system, the only
realistic way we have to look for these bugs is for people to use the
system. I just don't see how else to do it;
There are several packages in Sage which have test suites that we could run from
spkg-check. But people have not added the spkg-check file to Sage, so we can not
run the tests.
http://trac.sagemath.org/sage_trac/ticket/9767 # cliquer
http://trac.sagemath.org/sage_trac/ticket/9613 # linbox
http://trac.sagemath.org/sage_trac/ticket/9311 # ratpoints
and *many* others. Of the 100 or so standard packages in sage, only around 20
have the ability to run any self-tests of the packages when they are built. In
some cases, those test suites are *far* more comprehensive than the ones in
Sage. (I believe Pari is an exception, where the Sage doctests are more
comprehensive than the Pari tests).
If you look at the first and second columns of this ticket:
http://trac.sagemath.org/sage_trac/ticket/9281
you will see those where there is an spkg-check file, and there where there is
not one. Not every package in sage has the ability to do any self checks during
the build process, so we will never be able to get that list complete, but there
are a lot missing.
Dave
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
