On Jun 11, 2010, at 11:22 AM, Dr. David Kirkby wrote:
On 06/11/10 06:54 PM, kcrisman wrote:
Testing every single installed package could be
quite tricky, as likely the packages change in various spkgs over
time, but sometimes in subtle ways that an updater of an spkg
wouldn't
be aware of.
Well, it might be tricky, but at least the person updating the
package would be
aware of it, and would address that on the ticket. It might mean
some doctest
needs changing. But better to do that, then find several bits of a
package not
working - or worst still, giving the wrong answers.
But this assumes that only someone with intimate knowledge of an spkg
can update it. If a new package is added to an spkg, often that is
buried deep in release notes - often of some intermediate version
that
Sage didn't update to in the meantime. I understand the concern, but
keep in mind that in this case it is quite likely that fewer people
will update spkgs for mere bugfixes; only people who really know the
spkgs will update them, which could lead to much slower bugfixing.
Maybe that's ok.
I think sage/interfaces or sage/libs/x would be a fine place to put
specific tests like that, and spkg-installs should make sure the
package installed correctly and (if relevant) at least starts up and
seems to function.
I think every time maxima is updated, several doc tests need to be
too.
Yup, and of course we do this.
Perhaps each interface to something with packages that could
conceivably not build (Gap, maybe? Maxima?) could have a separate
test_default_packages command which would then just test itself.
I don't know enough about any of this, which is why I'm seeking
advice.
I know one of the golden rules of testing is that you should
create a test that
exhibits bugs detected.
Yes, I wasn't actually disputing this, just unsure where to do it in
this sort of case.
Anyway, enough virtual ink spilled/spilt on this. The real issue is
that one needs massive amounts of time to write the right kind of
doctests and documentation, and since the incentive to add it is not
so high in a volunteer project for many people (though thanks to
those
for whom it is!), getting to that point will take a long, long time.
IMHO, if Sage as any hope of being a viable alternative to Maple,
Mathematica or MATLAB, then writing decent documentation and test
procedures is a must.
Perhaps the incentive should be simple.
1) If you want to make the functions available for your own use, you
don't need to test them or document them.
2) If you want them incorporated into Sage, you must document them
well and test them extensively. If you don't know how to do that,
ask for help, but don't expect others to do all the legwork for you.
Isn't that already the policy?
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
