[Gretl-devel] RFC: $sigma & co.

[Allin Cottrell]

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.