On Sun, Jan 01, 2017 at 03:27:31PM -0800, PhilipNienhuis wrote:
Sebastian Schöps wrote
Olaf Till-2 wrote
On Sat, Dec 31, 2016 at 01:40:05AM -0800, Sebastian Schöps wrote:
However, I still believe that we should give up on the idea of supported
and
unsupported packages and just maintain a list of known packages (hosted
on
3rd party sites) that are compatible (i.e. have a Makefile like you
suggested recently).
I'd say that official packages must be carefully reviewed such that there
is no malicious code and that the code is (mathematically) correctly
working. I understand that Carnë checked formal correctness but not
contentwise (Carnë: right?). I think it would be more honest to maintain a
list and make packages less part of the Octave project itself. This would
also further reduce the effort for reviewers and submitters. Many packages
are doing their development anyhow somewhere external.
Of course, also for Octave there is no rigorius guarantee that all
functions give the correct answer, nonetheless the effort that peope
invest to ensure correctness is obviously much higher than for packages.
This is rather obvious since many packages require very specialized
knowledge, e.g., I can check rather easily if the pcg implementation is
correct but I have no clue how the algorithms of the interval package work
and it would take an incredible amout of my time to do a code review.
There's indeed more to it than just "working mathematically correctly".
Several OF packages interface to external software and data structures/data
files. Notable examples are the io and the mapping packages that I maintain.
I really don't expect an OF "leader" to be able to effectively review such
code. It is just too specialized. As regards quality in the sense of
"correctness" the best is to hope for code maturity, usually obtained by
prolonged use in the real world and fixing the bugs encountered there.
As far as quality is concerned all that an OF leader can do is review
package structure, check completeness of package documentation (easily
overlooked by package maintainers) and maybe stimulate tests covering the
complete package; all of this is very valuable in itself.
Add some cursory code style checks to the job and he/she runs out of time
....
Something more that can be cared for with 'supported' packages
(keeping the 'supported' notion):
- package licensing
- (some) consistency of contained functions with Octave, with other
packages, with ML (has been disputed, can require compromises from
package maintainers)
- excluding unmaintained packages
possible advantages for package maintainers of supported packages:
- repository is already available,
- common mailing list, common bug tracker, sometimes valuable help in
fixing bugs,
- maintaining 'the' <some_topic>-package, instead of maintaining 'just
another' <some_topic>-package,
- reputation of maintaining a supported package