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 ------------------------------------------------------- ------------------------------------------------------------------------ _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel