Release goals for 3.6

[Jordi Gutiérrez Hermoso]

Let us remember the discussion from February:

On 11 February 2011 14:16, John W. Eaton <address@hidden> wrote:
> I know, we just barely have 3.4 out there, but I'd like to take a look
> at what should be done for 3.6.
>
> First, I'd like to continue to try to shorten the release cycle.
> We've made some progress since the no release :
>
>  1.0: Feb 17 1994
>  1.1: Jan 12 1995  11 months!  Things were simpler back then...
>  2.0: Dec 10 1996  23 months
>  2.1: long series of widely used snapshots but no "stable" releases
>  3.0: Dec 21 2007  ???
>  3.2: Jun  5 2009  18 months
>  3.4: Feb  8 2011  20 months
>
> My goal is to cut the time between releases to 9-12 months, so that
> would mean starting the release process sometime in september this
> year. If the release cycle is much longer than a year, then it seems
> to become difficult to make releases. If they happen more
> frequently, maybe we won't pressure ourselves into trying for last
> minute perfection.

This means that if we keep with this plan, we have one more month
before we hit a feature freeze?

> Next, I have a few projects that I would personally like to work on
> (these might not all happen for 3.6, but they are things I'm
> currently most interested in):
>
>  * Improve textscan. I promised Ben Abbott that I would look at what
>    is needed to handle the textscan-specific format specifiers. I
>    started doing that, but never finished the job.

This seems to be well underway.

>  * Look at whether octave idx type should be an unsigned type. See
>    
> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-February/022980.html
>    for some motivation for a change like this.

I haven't seen any work on this. Has there been any?

>  * Fix lsode, dassl, daspk, etc. to accept an options structure as
>    an argument instead of using a global option structure (losde
>    options, dassl options, etc.). If possible, this should be done
>    in a way that allows a smooth transition, so that code using the
>    options functions can be deprecated but will continue to work for
>    at least one release cycle.

Same here, no work yet?

>  * Make the current FLTK+OpenGL plotting system work better so that
>    we can make it the default.  For this to happen, there are a lot
>    of little bugs that need to be fixed, plus we need to make
>    printing reliable.  If possible, we need to make printing work
>    even when a plot is not displayed on the screen.

This one is a big release goal. Do we have a specific set of bugs that
we should patch? We have several related to fltk in the bug tracker.
Perhaps begin by prioritising those? This one looks like a very
important user-visible change for 3.6.

>  * Integrate a GUI with the core Octave distribution.  My preference
>    would be to start with OctaveDE since I think it is doing the
>    right thing by embedding Octave rather than communicating with
>    Octave using pipes.  I'm willing to consider other alternatives,
>    but it is important to me that we have a way to interact with
>    Octave's command line without needing to completely reinvent
>    readline.

Quint, or as Jacob Dawid has been calling it recently, simply "the
Octave GUI", seems to be ready to at least be an experimental GUI for
3.6. It is doing readline and Jacob is doing a lot of work on it (plus
he keeps recruiting more people to help). I'm going to try to
integrate it with Octave's build system and push to Savannah on the
default branch within a few weeks. We can spend time after September
polishing it for release.

>  * Make a gtk+OpenGL graphics system.  Or use wxWidgets, or
>    something (anything!) that looks better than FLTK (sorry, FLTK
>    fans).

I don't think this is ready yet. Jacob expressed some interest in
making this work with Qt, but I don't believe he's managed to
understand how plotting works well enough to begin the Qt
implementation.

Somewhat related to the above, I'm a little worried with how difficult
binary distribution seems to have been for the 3.4.x series, and I
wish we would avoid this for 3.6. There isn't any excuse on my side
with Debian, just haven't gotten around to making packages, which is
embarrassing because compiling here is easier than on Macintosh
operating systems or Windows, but we should try to at least make sure
we can get Octave compiling on non-free OSes or try to not make it
harder for them. Jacob's GUI has an important problem for Windows here
because it's using ptys. Michael Goffioul (I think?) seems to be
skeptical that cygwin is the solution here. Is there anything else we
can do to make Windows distribution easier?

So, anyways, feature freeze in one month? Perhaps in two? Time to
think about it?

- Jordi G. H.