Re: [Gretl-devel] RFC: $sigma & co.
On Mon, 28 Apr 2008, Sven Schreiber wrote:
[re, reorganizing the $sigma and $vcv accessors]
Although I will be one of the (few?) affected users I agree with
Jack that $vcv should be changed, especially because it's very
simple to change $vcv to $sigma to get the scripts working
again. (And I like the functionality that $vcv will deliver in
VAR/VECM contexts.)
OK.
However, I still believe that backwards-incompatible changes
should be addressed a little more formally, and I have a couple
of mutually independent suggestions:
1. All function packages on the server must be tested to see if
they will be broken because of the change. Or to put it
differently: If they don't work any longer after the change,
that's officially considered a bug in gretl. Otherwise function
package contributors will get frustrated and the whole idea of
enhancing gretl with those contributions loses appeal.
Yes, that's a good idea. I currently have a large set of test
scripts that I run (with "known good" results) before putting out
a release. I should make sure that every contributed function
package is included in those tests.
Suppose we change something that breaks an existing package: I
guess it's OK if we're explicit about that, and put up a modified
version of the package that works with the new release? (With
judgment required, of course, on how often to do that sort of
thing.)
2. For each gretl release some notes (readme) are prepared which
complement the changelog. They explain the
backwards-incompatible changes and how to solve the associated
problems.
Yes, we should do that.
3. Another sourceforge tracker is introduced as a database for
incompatible changes, including information on when such a
change was introduced (date and version numbers) and how to deal
with it.
If you (or someone else) is willing to take charge of that, that's
fine by me.
4. There is a period during which the use of recently changed
functions triggers a warning that is printed in the output. The
period could be six months or the duration of one release cycle,
whichever is longer. (Six months because many Linux distros have
that rythm.)
Good idea, though the ease/difficulty of doing this could vary
quite a lot across cases.
If they are adopted, I guess I would be willing to contribute
the work behind suggestions 2 and 3.
Great!
Number 1 is two-fold: the testing would need volunteers
("package maintainers"?), but simply agreeing to the bug policy
is just a decision, not work.
I think it would be easier to roll such tests into the existing
gretl regression suite. I can make this available via the web.
Package maintainers could play a useful role, however, by
contributing scripts that exercise their packages.
Allin.