Octave 8 Release Tasks

I’m creating a new topic to track work on the Octave 8 release. I will pin it to the top of the discussion until complete.

1 Like

The repository directory etc/ has files on hacking Octave and what do immediately before a release (CHECKLIST.md), but there is no detailed list of the activities that should happen before a release (merge default to stable, grammarcheck and spellcheck documentation, make a call for translations, produce a release candidate, etc.). We should probably copy the checklist that has been used for previous releases into the Mercurial repository.

EDIT: I added a new file RELEASE_CHECKLIST.md in the etc directory which summarizes the steps for a release (http://hg.savannah.gnu.org/hgweb/octave/rev/71f9f7210b7c).

It would be nice if we could have an Octave 8 release before year end. Otherwise, we will need to update all the copyright notices on the stable branch. I know that @jwe has this process mostly automated, but even so it would be nice not to have to do that in the middle of freezing the release version.

Re-posting a comment from @mmuetzel:

Now that default has been merged to stable, should we add a “stable” label to the “Release” list on Savannah? Currently there is no good way to mark reports that should (or could) be fixed on the stable branch.

I’m not sure if updating the copyright notices is something we need to worry about for a release date. It probably doesn’t make much difference if those dates are updated for the first or the second minor release of Octave 8.

We should probably start collecting bugs that should be fixed for Octave 8. (A label in Savannah might help for this.)
Not a complete list at all, but imho we should try to fix bug #63388 (and possibly other hard crashes?) if possible.
Also, I’d prefer if we understood why the test suite crashes Octave on the Windows GitHub runners. See: Test suite crash on Windows CI.

It is not absolutely required since the copyright exists the moment the code is changed regardless of whether we announce our claim to it. However, it is best practice and I think we should follow it in this case unless there is a compelling reason not to.

Sorry. I might have been unclear. I didn’t intent to propose not updating the copyright year at all. I just wanted to express that this argument might not be a compelling reason to push for a release this year because we need to update the copyright year anyway. (Be it before or after a potential release date.)

The checklist for the Octave 8 release process is at 8.1 Release Checklist - Octave.

The current summary of Octave bugs is at GNU Octave - Savannah Bugs and Patches

I’ve started working through the checklist. There is a new release tag 8.0.90 on Savannah to tag bugs associated with the first release candidate or which must be fixed before the 8.1.0 release.

A bug report where translators can upload *.ts translation files is at GNU Octave - Bugs: bug #63404, Translation files (*.ts) for... [Savannah]

Could someone contact Torsten about generating the base tranlation files?

paging @ttl

I was trying to go through the release checklist for the documentation. One of the items is to make sure all functions, that are not internal, have an entry in the Octave manual (a @DOCSTRING(...) entry). I have fixed everything except for the function desktop. Is this function too experimental to be put in the manual?

I ask because when I invoked the function it told me it couldn’t continue because I didn’t have the experimental terminal widget. This brings up a related question. If I run octave --help from the shell one of the command line options is

  --experimental-terminal-widget
                          Use new experimental terminal widget in the GUI.

however this option is not documented in the basics.txi file in the manual. Should it be?

EDIT (11/23/22): The --server command line option is also undocumented. Should it be?

  --server                Enter server mode at startup.

hasn’t the experimental terminal widget been somewhat dormant for a while? What state is it in?

I personally thing the ‘all functions in manual’ should have an exception for ‘not really released’ functions. Either that, or we make an ‘experimental, play at your own risk but please send feedback’ section of the manual.

That’s already my understanding of what we do. For example, we don’t include internal functions such as __debug_octave__. It’s also the way I would vote if this were a vote.

Perhaps the small wrinkle on this is that desktop is a Matlab-function so for compatibility reasons we might like to document it. Given that it already exists, if someone types desktop the function will get invoked rather than a warning message from __unimplemented__.m.

Some work has been done on the new Qt terminal widget to improve what I first pushed, but it is still incomplete.

I’d opt to leave desktop undocumented for now since it doesn’t really do much useful and things don’t work 100% correctly yet even with the experimental widget. It seems OK to me if someone tries it and gets a message about the experimental terminal widget instead of the unimplemented message.

Regarding the server mode, there are these messages related to that when building with fsanitize=undefined and running make check:

../libinterp/corefcn/interpreter.h:169:68: runtime error: member call on address 0x7fb34c0058d8 which does not point to an object of type 'tree_evaluator'
0x7fb34c0058d8: note: object is of type 'octave::tree_walker'
 00 00 00 00  c8 c6 e2 9e b3 7f 00 00  80 4a 00 4c b3 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'octave::tree_walker'

../libinterp/parse-tree/pt-eval.h:187:44: runtime error: member access within address 0x7fb34c0058d8 which does not point to an object of type 'tree_evaluator'
0x7fb34c0058d8: note: object is of type 'octave::tree_walker'
 00 00 00 00  c8 c6 e2 9e b3 7f 00 00  80 4a 00 4c b3 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'octave::tree_walker'

Line 169 of libinterp/corefcn/interpreter.h:

    168 
    169     bool server_mode (void) const { return m_evaluator.server_mode (); }
    170 

Line 187 of libinterp/parse-tree/pt-eval.h:

    186 
    187     bool server_mode (void) const { return m_server_mode; }
    188 

Probably best to leave the server mode undocumented. That would give more time to investigate the messages and see if they’re false positives.

I checked in a change for the release task of updating the manual to include undocumented functions (http://hg.savannah.gnu.org/hgweb/octave/rev/4b80982e0af8). Per this discussion, I left out desktop and did not document the command line option --server.

Please file a bug report or provide some details here about exactly how you are compiling with -fsanitize=undefined and how you are running make check so that you see those messages.

@jwe: I created a bug report for it: GNU Octave - Bugs: bug #63416, Messages from building with... [Savannah]

2022/11/28: An update.

After 7 days, things are looking pretty good. Translation files have been updated for widely supported languages. The documentation review is complete except for one item. The copyrights are correct for this year (to be fair, this was done quite a while ago). The test suite is passing on the buildbots and issues identified by the address sanitizer have been fixed.

I think the two issues that remain before making a release candidate are 1) to identify any bugs on Savannah that must be fixed before the release and 2) do a code style review of the C++ code (I already did the m-files).