Neil Hopcroft

There were a number of comments to my initial mail to the maintainers mail list.

• “reviving the fixed-point arithmetic package would be great. It’s gotten badly bit-rotten, and is of interest to people working with certain digital signal processing hardware.”
• “Having regularly updated reports on the status of Octave packages would be great. Even better would be to have some code coverage statistics associated to the unit tests, but we’re not there yet.”
• “In your post “Octave Packages CI build dependencies “, you report “Build error” for stk, but you don’t provide the version of stk (nor the version of Octave) that you have tested. Could you please tell me more about this “Build error”? A release was made very recently (2.3.0), could you try it and see if the build error is still there?”
• “Neat. Would you like your blog to be syndicated at http://planet.octave.org ?”
• “Btw, we already have code coverage for core Octave. It’s part of our Hydra builds: http://hydra.nixos.org/jobset/gnu/octave-default#tabs-jobs”…”But it covers C++ code, not m-files, right ?”

Which boils down to a few useful things for me to do:

• Get all the package tests working and reporting results in a sensible way
• Reporting any problems I find along the way to the current maintainers where there are any
• Get some .m file coverage tests working for the packages
• Pick up the fixed package and bring it up to releasable standard