Re: Release goals for 3.6

[Konstantinos Poulios]

2011/8/2 Jordi Gutiérrez Hermoso <address@hidden>:
> 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.
>

I'd like to just add my point of view concerning the fltk graphics.
There are two features that I consider important for making fltk the
default backend:

1. Sub- and superscript support in the ft_renderer
2. An issue with a text baseline shift in gl2ps (first step would be
to make a bug report for this :) )

Unfortunately I am not expected to have time to work on them soon, so
this is more like a wish-list than a work-plan.

Besides these two points, I consider that the fltk backend is in
pretty good shape right now.

Best regards

Kostas

P.S. The changeset e77284b6dac6 would be a nice candidate for the
stable branch, if 3.6 takes longer to be released.