Re: Octave Forge -- Looking for a new leader

[Olaf Till]

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

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature