Re: Removing packages from Octave Forge

[Philip Nienhuis]

Julien Bect wrote
> On 10/01/2014 11:09, Alexander Barth wrote:
>> To improve code quality, I would rather suggest to ask the maintainers 
>> (if they can be reached) to add a test script to their package which 
>> verifies the functioning of the package as a whole (e.g. 
>> test_
> <packagename>
> .m). This script could call for exemple the test 
>> code the individual file with the test function but it would also 
>> check if the functions work correctly together.  I can write such a 
>> test script for mapping. If a package fails its test suite, then we 
>> have, in my oppion, a more objective way to decide that this package 
>> should be removed from the "official" list of packages.
> 
> I like this idea very much. I suggest to call the test function 
> PKG_TEST, in the spirit of PKG_ADD and PKG_DEL, and to make it possible 
> for package users to run the test suite using, for instance, "pkg test 
> PackageName". Just my two cents.

In principle I second this; but it just won't work on all packages for all
functions.

E.g., in the io package I have some test scripts for all spreadsheet I/O
functionality, that adapt to the situation on the box the io pkg gets
installed on.
But the io package also contains various functions that have been there for
a long time and that I don't really maintain. Some were contributed, all
still seem to work and/or compile flawlessly. I've restyled some and for
some even added some extremely simple tests; but as I'm not familiar with
the purpose they serve I simply can't create really useful practical tests
for them.

Then consider the general or miscellaneous packages, collections of
functions with widely varying functionality. How to test text_wait bar or
solvesudoku? I don't doubt it can somehow be done, but not without
overstretching or unduly mis-prioritizing the limited developer time we have
here.

Other hard-to-test issues concern what happens during package
installation/uninstallation - I got bitten myself lately by such issues.

In a more positive sense, the way to go -as always- is to just start with
some test scripts for some packages that don't have tests yet, rather than
rolling out a scheme for all packages. We'll see what problems we get on the
way.
I'd advise Alexander to proceed making a test script for the mapping package
(that I also use, sporadically) even if he isn't package maintainer.

I had to invest quite a bit of time in making & debugging the test scripts
for spreadsheet support, but looking backward I can only say that it really
paid off in making maintenance easier (plus, I learned a lot from it, and it
was fun).
So apart from discriminating between working and broken packages, formal
test scripts also can help keeping package maintenance down.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Removing-packages-from-Octave-Forge-tp4660799p4660903.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.