Re: Plans for Octave 6.1 release

[Kai Torben Ohlhus]

On 12/7/19 7:01 AM, Rik wrote:
> All,
> 
> We are trying to get in the habit of making more frequent releases of
> Octave, at least yearly.  Traditionally the release is in late December or
> early January.  I have worked as the release manager for the last four
> releases, but don't have time to reprise that role this year.
> 
> The first question is whether there is someone on the Maintainer's list who
> does have the time and inclination to be the manager this year?
> 
> The checklist of instructions is at etc/RELEASE.CHECKLIST and the
> accompanying bug fix template is at etc/RELEASE.BUG_FIX_LIST. 
> Traditionally I have placed these as pages on the Octave Wiki at
> https://wiki.octave.org/Category:Development so that everyone could see the
> status, and make changes without requiring excessive permissions.  I have
> started things off by performing action item #1 : updating gnulib repo.
> 
> If no one has enough time to be manager then we will fall back to doing a
> point release in January with the expectation that it will require a minor
> release shortly thereafter because there has been less checking.  This
> would be in keeping with modern practice which is to release every six
> weeks and rely on users for bug testing.  The Octave code base, even on the
> development branch, always compiles and almost always passes 'make check'
> so this is acceptable.
> 
> --Rik
> 


Dear Rik,

Your efforts for GNU Octave are really outstanding and I am very
thankful that you managed the passed releases with lots of work,
passion, and care for the details.  The same thanks go as well to many
other contributors who almost every day ensure my "hg pull" command to
grab fixes for bugs and many useful improvements for free (as in speech
and beer) ;-)  Please resist from managing this release if your time is
too limited.

You and Markus already got things started.  Additionally, I overhauled
the wiki [1] and hope to have introduced a useful "innovation" by using
"clever" linking to Savannah to track the state of the bugs, rather than
duplicating the data in a separate wiki page, that gets outdated too
fast and is hard to maintain consistently.  In the past releases I
quickly lost the overview with this approach.

After you raised the bar by your great work on the past releases, Rik, I
think hardly anyone dares to step into your shoes ^^  By reviewing [1],
I am able to perform most of the organizational steps myself.  Thus I
hope others join into working on [1] until the bottom of that page is
reached.

When it comes to build release candidates, my machine is able to do
this.  But I think jwe has to sign and upload these builds to [2], right?

My personal expectation is no 6.1 release before February 2020 [3].  But
as 5.1.0 is already long time ago, I vote for another 5.2.0 stable
release before Christmas, followed by efforts to release 6.1.0.  On the
stable branch, there are

   hg log -r "release-5-1-0:" -b stable | grep "changeset" | wc -l

104 more or less important changes accumulated over 10 months users are
waiting for.  This stable release does not need that much effort [1], as
it is stable, and I can prepare the stable branch for 5.2.0.  Opinions?

Best,
Kai


[1] https://wiki.octave.org/6.1_Release_Checklist
[2] https://ftp.gnu.org/gnu/octave/
[3]
https://github.com/octave-de/octave_slides/blob/00a00e89e79a13d4c42ef6b12491ff2107d69a64/jupyter/mailing_list_activity.ipynb