octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing packages from Octave Forge


From: Alexander Barth
Subject: Re: Removing packages from Octave Forge
Date: Fri, 10 Jan 2014 17:01:09 +0100




On Fri, Jan 10, 2014 at 1:45 PM, Mike Miller <address@hidden> wrote:
On Fri, 10 Jan 2014 07:22:58 -0500, Thomas Weber wrote:
> On Fri, Jan 10, 2014 at 11:09:33AM +0100, 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).
>
> At least for Debian, that is not needed. We run all (non-interactive)
> tests in .m and .cc files when building a package. Now, in theory, a
> failing test should prevent the package from being uploaded. In
> practice, some packages have long-standing failures in their testsuite.

Even outside of Debian, we don't need new syntax or new conventions for
running package tests. Please, please, do not start committing test
scripts to package repositories. Just write %!test blocks for your
functions and use Octave's runtests command. If anything, maybe file a
wishlist bug for a "pkg test" command that is just a thin wrapper around
runtests.

Thank you for pointing runtests out. I was not aware of this script and it would be indeed sufficient in my opinion to test the well functioning of a package. The "pkg test" command would be a convenient way for the user to test the package.

However, if the package should also work on matlab, one should also be able to use the test suite on matlab. I don't know if this possible with %!test blocks. Even if the package should only work on octave, but implements a functionality in matlab, it is very useful to be able to run the test suite in matlab in order to make sure that the test suite is correct.

I would like to come back to the original question about removing package from octave forge (rather than disgressing about whether one should use test blocks or not). I think that it is preferable to base such decision if the test code fails or not (rather than release date). If a package does not contain a test suite and if the maintainer (or anybody else) has no time to write one, it can dropped from the "official list". But if the package still works well, I would suggest to keep it visible.

regards,
Alex


 

--
mike


reply via email to

[Prev in Thread] Current Thread [Next in Thread]