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@univpm.it
   http://www2.econ.univpm.it/servizi/hpp/lucchetti