Re: [Gretl-devel] about adding function packages to the menus
On Thu, 19 Jan 2017, Sven Schreiber wrote:
Hi,
I want to raise a "policy question". Currently contributed function packages
can decide "for themselves" whether they want to be added somewhere in the
gretl menus. IIRC this was borrowed from the gretl add-ons.
For the outsider/user this blurs the distinction between core gretl and the
contributions, which is exactly the purpose of the mechanism.
However, there is a difference in the amount of testing that goes into a
functionality in core gretl compared to the testing that a function package
receives. (I'm talking about the testing done by the code authors, not about
the quite superficial checks that Allin, Jack, and I are doing when moving a
submitted package to the public server. And I am also talking about packages
written by myself, this is not meant as criticizing others.)
So the problem is that to the user package bugs would look like gretl bugs,
which makes gretl look less reliable than it is.
My first suggestion therefore is to include the "author" field not only in
the package list in the "on server" window, but also in the list window
displaying the locally installed packages. This should make it more
transparent that these are _contributed_ packages, and not core gretl. (Also
the ego of the authors might benefit a little.)
I don't see why we shouldn't do this.
Secondly, my proposal is that before a package is allowed to appear
in the
menus it would need to pass some additional checks. For example, this check
could be provided by replicating in the example script some known-good
result.
I don't like this very much. When you install a package, you give it
explicit permission to show up in the main GUI somewhere, so you can't
claim "nobody told me". And besides, giving access to the menus as if it
was some badge of honour that you earn by proving your package replicates
some known benchmark would be (a) practically impossible in some cases
(think eg of Ignacio's HEGY package) (b) very burdensome in terms of QA
assurance (c) very easy to circumvent (edit the package - add the menu
property - save the package).
BTW, there is a real-world experience behind my suggestion. Of course
this
policy change would not prevent all bugs; for example I remember a bug
affecting (some) results in the SVAR addon, and that addon was certainly
tested quite thoroughly. But still I think it could help.
One thing that we could do, in order to inform the user on the degree of
testing a certain package has undergone, is to give package authors the
possibility of writing a short working paper (in the "gretl wp"
collection) where replication of known examples is performed, like
Claudia and myself did for DPB, and advertise that in the package
description.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------