Octave 3.1.52 available for ftp

[John W. Eaton-3]

A new snapshot of Octave is now available for ftp from ftp.octave.org in the
directory /pub/octave/bleeding-edge:

  52a5945e792574ffd7519f7d48f370dc  octave-3.1.52.tar.bz2
  25e0d448fe4c103495982fc95765e700  octave-3.1.52.tar.gz
  2a12ef2bd5721b917c788a3039d93192  octave-3.1.51-3.1.52.patch.bz2
  18086ea4fb815082cc1e0038493c7d76  octave-3.1.51-3.1.52.patch.gz

  -rw-r--r-- 1 506 1012 10742307 Feb 09 21:56 octave-3.1.52.tar.bz2
  -rw-r--r-- 1 506 1012 12436955 Feb 09 21:58 octave-3.1.52.tar.gz
  -rw-r--r-- 1 506 1012  1306276 Feb 09 21:59 octave-3.1.51-3.1.52.patch.bz2
  -rw-r--r-- 1 506 1012  1620539 Feb 09 21:59 octave-3.1.51-3.1.52.patch.gz

The snapshot is tagged in the usual way (ss-3-1-52) in the Mercurial
archive and will be marked as the "development" version of
Octave on the download page of the Octave web site.

Please remember that these snapshots are provided for testing
purposes.  I do not consider them to be Octave releases.  If people
think there will be confusion because of the version number, then we
can add a notice to the Octave startup message.  Changing the version
number to something like ss-2008-07-21 is not an option because it
will cause trouble with typical version comparison functions (for
example, that are sometimes used for building Octave Forge packages).

This snapshot includes the new experimental OpenGL-based graphics
code, but the gnuplot backend is used by default.  Assuming you have
all the required libraries and have built the OpenGL bits properly,
you should be able to switch to the new backend with the commands

  input_event_hook ("__fltk_redraw__");
  __init_fltk__ ();
  set (0, "defaultfigure__backend__", "fltk");

I'm sure there will be a simpler way to do this once the new backend
code is more mature.

PLEASE DO NOT REPORT THAT AXES LABELS AND OTHER TEXT OBJECTS ARE NOT
DISPLAYED WITH THE NEW GRAPHICS BACKEND.  Although the FTGL library is
detected and linked, it is not yet used to actually put text on the
plot window.  We could use a few more hands to help with implementing
that...

jwe

[Michael Goffioul-2]

On Mon, Feb 9, 2009 at 10:08 PM, John W. Eaton <jwe@...> wrote:

> A new snapshot of Octave is now available for ftp from ftp.octave.org in the
> directory /pub/octave/bleeding-edge:
>
>  52a5945e792574ffd7519f7d48f370dc  octave-3.1.52.tar.bz2
>  25e0d448fe4c103495982fc95765e700  octave-3.1.52.tar.gz
>  2a12ef2bd5721b917c788a3039d93192  octave-3.1.51-3.1.52.patch.bz2
>  18086ea4fb815082cc1e0038493c7d76  octave-3.1.51-3.1.52.patch.gz
>
>  -rw-r--r-- 1 506 1012 10742307 Feb 09 21:56 octave-3.1.52.tar.bz2
>  -rw-r--r-- 1 506 1012 12436955 Feb 09 21:58 octave-3.1.52.tar.gz
>  -rw-r--r-- 1 506 1012  1306276 Feb 09 21:59 octave-3.1.51-3.1.52.patch.bz2
>  -rw-r--r-- 1 506 1012  1620539 Feb 09 21:59 octave-3.1.51-3.1.52.patch.gz
>
> The snapshot is tagged in the usual way (ss-3-1-52) in the Mercurial
> archive and will be marked as the "development" version of
> Octave on the download page of the Octave web site.
>
> Please remember that these snapshots are provided for testing
> purposes.  I do not consider them to be Octave releases.  If people
> think there will be confusion because of the version number, then we
> can add a notice to the Octave startup message.  Changing the version
> number to something like ss-2008-07-21 is not an option because it
> will cause trouble with typical version comparison functions (for
> example, that are sometimes used for building Octave Forge packages).
>
> This snapshot includes the new experimental OpenGL-based graphics
> code, but the gnuplot backend is used by default.  Assuming you have
> all the required libraries and have built the OpenGL bits properly,
> you should be able to switch to the new backend with the commands
>
>  input_event_hook ("__fltk_redraw__");
>  __init_fltk__ ();
>  set (0, "defaultfigure__backend__", "fltk");
>
> I'm sure there will be a simpler way to do this once the new backend
> code is more mature.

Yes, using the "backend" function, which is part of octave now.

Michael.

[John W. Eaton-3]

On 10-Feb-2009, Michael Goffioul wrote:

| On Mon, Feb 9, 2009 at 10:08 PM, John W. Eaton <jwe@...> wrote:
|
| > you should be able to switch to the new backend with the commands
| >
| >  input_event_hook ("__fltk_redraw__");
| >  __init_fltk__ ();
| >  set (0, "defaultfigure__backend__", "fltk");
| >
| > I'm sure there will be a simpler way to do this once the new backend
| > code is more mature.
|
| Yes, using the "backend" function, which is part of octave now.

Thanks, I thought there was something better now, but I couldn't
remember what.  I changed the information in my template file so this
will be fixed in my next snapshot announcement.

jwe

[WMennerich]

Hello,
does this new snapshot include the patches for 3.0.4?
If not, is 3.0.3 included?

Best Regards,

Wolfgang

[John W. Eaton-3]

On 11-Feb-2009, WMennerich wrote:

| does this new snapshot include the patches for 3.0.4?
| If not, is 3.0.3 included?

3.1.x and 3.0.x are separate branches, so I don't really understand
the question.

jwe

[WMennerich]

Both branches come from 3.0.
Hence, the patches included in 3.0.1, 3.0.2, 3.0.3 and 3.0.4
could also be necessary for 3.1.5x as long as they touch only
parts of the sources which are not different between 3.0 and 3.1.5x .
Or are the two branches already to different?

Wolfgang

[John W. Eaton-3]

On 12-Feb-2009, WMennerich wrote:

| Both branches come from 3.0.
| Hence, the patches included in 3.0.1, 3.0.2, 3.0.3 and 3.0.4
| could also be necessary for 3.1.5x as long as they touch only
| parts of the sources which are not different between 3.0 and 3.1.5x .
| Or are the two branches already to different?

The general idea is that bugs are fixed in the main development branch
3.1, and then patches that are appropriate for the stable branch are
applied there.

In the 3.0.x branch, we applied a lot of patches, attempting to fix
many of the bugs reported, possibly at the expense of stability.

In the future, I would like to see us only applying patches to the
stable branch that fix regressions from previously released versions
of Octave.  Otherwise, I think applying too many patches does not
tend to improve the stability of the series of "stable" releases, and
takes up effort that could be better used on the main development
branch.

So, I would like to see our guidelines for the next stable release
series be

  * If the bug was present in past versions of Octave (so not a
    regression), fix it in the development branch only.

  * If a bug appears in the stable version that was not present in
    previous versions (a regression), then the problem should be fixed
    in both the development and stable branches.

No other patches should be applied to the stable branch without some
discussion, and I would argue against applying the patch in nearly all
cases.  I would probably only argue in favor of applying a patch for a
bug that is not a regression if it is causes a serious problem, like
making Octave crash.  But it seems likely that problems like that
would also be regressions.

Comments?

jwe

[Thomas Weber-8]

Am Donnerstag, den 12.02.2009, 11:53 -0500 schrieb John W. Eaton:

> On 12-Feb-2009, WMennerich wrote:
>
> | Both branches come from 3.0.
> | Hence, the patches included in 3.0.1, 3.0.2, 3.0.3 and 3.0.4
> | could also be necessary for 3.1.5x as long as they touch only
> | parts of the sources which are not different between 3.0 and 3.1.5x .
> | Or are the two branches already to different?
>
> The general idea is that bugs are fixed in the main development branch
> 3.1, and then patches that are appropriate for the stable branch are
> applied there.
>
> In the 3.0.x branch, we applied a lot of patches, attempting to fix
> many of the bugs reported, possibly at the expense of stability.
>
> In the future, I would like to see us only applying patches to the
> stable branch that fix regressions from previously released versions
> of Octave.  Otherwise, I think applying too many patches does not
> tend to improve the stability of the series of "stable" releases, and
> takes up effort that could be better used on the main development
> branch.
>
> So, I would like to see our guidelines for the next stable release
> series be
>
>   * If the bug was present in past versions of Octave (so not a
>     regression), fix it in the development branch only.
>
>   * If a bug appears in the stable version that was not present in
>     previous versions (a regression), then the problem should be fixed
>     in both the development and stable branches.
>
> No other patches should be applied to the stable branch without some
> discussion, and I would argue against applying the patch in nearly all
> cases.  I would probably only argue in favor of applying a patch for a
> bug that is not a regression if it is causes a serious problem, like
> making Octave crash.  But it seems likely that problems like that
> would also be regressions.
>
> Comments?

This boils down to not fixing bugs, but only errors introduced when
fixing other bugs. Frankly, I'd consider such releases pointless. This
forces anybody on the development branch if they want a fix for a bug
that was also in a previous revision.

Additionally, the work for checking older versions is non-trivial. Which
older versions do you want to check? Who is going to check it?
Distributions will either have an older version of the stable branch or
only the current one, against which the bug is reported.

Do you have any indication for a loss in stability of the stable branch?
I'd say it's still stable as a rock.

        Thomas

[John W. Eaton-3]

On 12-Feb-2009, Thomas Weber wrote:

| This boils down to not fixing bugs, but only errors introduced when
| fixing other bugs. Frankly, I'd consider such releases pointless.

I don't think it is pointless to fix regressions, and they can also be
introduced when adding new functionality, not just when fixing bugs.

These guidelines are essentially the same as used for GCC releases.

| Additionally, the work for checking older versions is non-trivial. Which
| older versions do you want to check? Who is going to check it?

Typically, I think we see bug reports that say things like "this used
to work, but when I upgraded it failed".

| Do you have any indication for a loss in stability of the stable branch?
| I'd say it's still stable as a rock.

Leading up to 3.0.4, I started to see reports about problems (mostly
graphics, I think) that were introduced when transplanting patches
from 3.1.x because too much had changed (like the order of the list of
child handles) and the patches were not adapted.  Adapting some
patches like this tends to lead to trouble because the patches are not
all independent.  Knowing what is safe to include isn't always clear.

jwe

[Søren Hauberg]

tor, 12 02 2009 kl. 11:53 -0500, skrev John W. Eaton:
> Comments?

I agree! "stable" should be stable, which means as little as possible
should change.

Søren

[John W. Eaton-3]

On 12-Feb-2009, Søren Hauberg wrote:

| tor, 12 02 2009 kl. 11:53 -0500, skrev John W. Eaton:
| > Comments?
|
| I agree! "stable" should be stable, which means as little as possible
| should change.

I would also like to add that there is nothing that says we even have
to provide a series of stable bug fixing releases.  But if we decide
to do that, then I would like to resist the urge to turn the stable
release series into a separate line of development with many changes
because I don't think that helps stability, and more importantly, it
is a time sink that takes effort away from the main development
branch.  Even importing changes from the development branch takes
time, and there is (as we have seen) the risk that importing those
changes can introduce new bugs, especially once the development branch
has changed significantly.

jwe

[Thomas Weber-8]

Am Donnerstag, den 12.02.2009, 12:56 -0500 schrieb John W. Eaton:
> On 12-Feb-2009, Thomas Weber wrote:
>
> | This boils down to not fixing bugs, but only errors introduced when
> | fixing other bugs. Frankly, I'd consider such releases pointless.
>
> I don't think it is pointless to fix regressions, and they can also be
> introduced when adding new functionality, not just when fixing bugs.
>
> These guidelines are essentially the same as used for GCC releases.

Given that I'm still stuck on GCC 4.1 for compiling Octave on ARM/Linux,
I'm a little bit biased. In other words, I'm not convinced by GCC's
development model.


> | Additionally, the work for checking older versions is non-trivial. Which
> | older versions do you want to check? Who is going to check it?
>
> Typically, I think we see bug reports that say things like "this used
> to work, but when I upgraded it failed".

Yes, but this stuff might be arch-specific or library specific. After an
upgrade (especially if its a distribution), there's no guaranteed way
back, meaning something might be failing, but it's not Octave's fault.

        Thomas

[Rafael Laboissiere]

* John W. Eaton <jwe@...> [2009-02-12 15:30]:

> On 12-Feb-2009, Søren Hauberg wrote:
>
> | tor, 12 02 2009 kl. 11:53 -0500, skrev John W. Eaton:
> | > Comments?
> |
> | I agree! "stable" should be stable, which means as little as possible
> | should change.
>
> I would also like to add that there is nothing that says we even have
> to provide a series of stable bug fixing releases.  But if we decide
> to do that, then I would like to resist the urge to turn the stable
> release series into a separate line of development with many changes
> because I don't think that helps stability, and more importantly, it
> is a time sink that takes effort away from the main development
> branch.

Putting my Debian package maintainer hat on , I must say that we (the DOG,
Debian Octave Group) have been doing this kind of "stable bug fixing" work
for the Debian packages since ages. Indeed, it is a lot of work, but we need
to close the bug reports that are filed against our packages by our users.

I tend to agree with Thomas that is is important to provide a stable branch
that is alive and as bug-free as we can.  However, I also agree with John
that this is a time sink for the upstream developers.  On the other hand, if
people with enough free time are willing to do it, like Jaroslav recently,
why not do it?  Of course, porting fixes from the development branch must be
done with extreme care.  This is what we usually do in the DOG.

--
Rafael

[Søren Hauberg]

fre, 13 02 2009 kl. 10:31 +0100, skrev Rafael Laboissiere:

> Putting my Debian package maintainer hat on , I must say that we (the DOG,
> Debian Octave Group) have been doing this kind of "stable bug fixing" work
> for the Debian packages since ages. Indeed, it is a lot of work, but we need
> to close the bug reports that are filed against our packages by our users.
>
> I tend to agree with Thomas that is is important to provide a stable branch
> that is alive and as bug-free as we can.  However, I also agree with John
> that this is a time sink for the upstream developers.  On the other hand, if
> people with enough free time are willing to do it, like Jaroslav recently,
> why not do it?  Of course, porting fixes from the development branch must be
> done with extreme care.  This is what we usually do in the DOG.

I'm saying this, without knowing anything about anything, so feel free
to consider this pure bullshit...

If the DOG is doing this kind of work, why can't you guys just be the
release managers for the stable series? It just sounds like there is a
large overlap between maintaining the stable branch and maintaining
Octave in a distribution.

Søren

[Rafael Laboissiere]

* Søren Hauberg <soren@...> [2009-02-13 10:56]:

> I'm saying this, without knowing anything about anything, so feel free
> to consider this pure bullshit...

Yes, it is sort of bullshit :-) In other words, don't push more work on us!

> If the DOG is doing this kind of work, why can't you guys just be the
> release managers for the stable series? It just sounds like there is a
> large overlap between maintaining the stable branch and maintaining
> Octave in a distribution.

Yes, the overlap is non negligible but I think they are two fundamentally
different tasks.  The DOG mission is to make the Octave-related Debian
packages [1] "bug free", in the sense that we take care of the bug reports
filed against the packages through our BTS [2].  Nearly all fixes in the
packages are contributed upstream, though.  Another important task of the
DOG is the global integration of all Octave-related packages (e.g. from
Octave-Forge).

This is very different from maintaining the stable branch of Octave, which
imply hanging on the mailing lists, going through the bug reports in
bug@..., coping with the proposed changesets, and preparing the
actual release tarballs.

(Not so) unrelated to the discussion in this thread: without a ticketing
system for managing bug reports, feature requests, and patches it will be
quite to do a coordinate development effort.

[1] http://qa.debian.org/developer.php?login=pkg-octave-devel@...
[2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=pkg-octave-devel%40lists.alioth.debian.org

--
Rafael

[John W. Eaton-3]

On 13-Feb-2009, Rafael Laboissiere wrote:

| (Not so) unrelated to the discussion in this thread: without a ticketing
| system for managing bug reports, feature requests, and patches it will be
| quite to do a coordinate development effort.

Yeah, we need something.

I'm going to propose going with the bug tracking system that is
already available at savannah.  It's not perfect, but it is better
than nothing, and we don't have to install or maintain the tracking
system itself.  The biggest hurdle in the transition to using it will
probably be fixing all the documents that tell people to send reports
to the bug@... mailing list, and then getting people to
actually use the new system.  Including the people who are fixing bugs
and are used to simply responding by email to a report.

jwe

[Thomas Weber-8]

On Fri, Feb 13, 2009 at 10:56:18AM +0100, Søren Hauberg wrote:

> fre, 13 02 2009 kl. 10:31 +0100, skrev Rafael Laboissiere:
> > Putting my Debian package maintainer hat on , I must say that we (the DOG,
> > Debian Octave Group) have been doing this kind of "stable bug fixing" work
> > for the Debian packages since ages. Indeed, it is a lot of work, but we need
> > to close the bug reports that are filed against our packages by our users.
> >
> > I tend to agree with Thomas that is is important to provide a stable branch
> > that is alive and as bug-free as we can.  However, I also agree with John
> > that this is a time sink for the upstream developers.  On the other hand, if
> > people with enough free time are willing to do it, like Jaroslav recently,
> > why not do it?  Of course, porting fixes from the development branch must be
> > done with extreme care.  This is what we usually do in the DOG.
>
> I'm saying this, without knowing anything about anything, so feel free
> to consider this pure bullshit...
>
> If the DOG is doing this kind of work, why can't you guys just be the
> release managers for the stable series? It just sounds like there is a
> large overlap between maintaining the stable branch and maintaining
> Octave in a distribution.

There is at least one reason why I don't like such a proposal (and they
are different from Rafael's). First, I believe that an original software
maintainer should almost *never* be a package maintainer for a
distribution. Such things result in conflicts of interests. Example: We
had a bug in Debian that the uninstall process of an octave-forge
package failed. It turned out that pkg.m throws an error when called
without an existing /usr/share/octave/packages directory (we come to
this situation as the Debian package manager dpkg removes the then empty
directory /usr/share/octave/packages)

>From a distributions point of view, that is a bug. I'm not so sure about
Octave. It's a valid point of view to say that calling 'pkg rebuild'
with a non-existing /u/s/o/p directory is a user-error.

A different point of view are platforms. I use Linux almost exclusively,
so I don't really care about other platfoms (ignoring that I have no
chance to actually test an installation on a Windows system).

        Thomas

[Thomas Weber-8]

On Thu, Feb 12, 2009 at 03:30:33PM -0500, John W. Eaton wrote:

> On 12-Feb-2009, Søren Hauberg wrote:
>
> | tor, 12 02 2009 kl. 11:53 -0500, skrev John W. Eaton:
> | > Comments?
> |
> | I agree! "stable" should be stable, which means as little as possible
> | should change.
>
> I would also like to add that there is nothing that says we even have
> to provide a series of stable bug fixing releases.  

What alternative do you have in mind? Releasing 3.0 and then nothing
until 3.2?

        Thomas

[John W. Eaton-3]

On 14-Feb-2009, Thomas Weber wrote:

| What alternative do you have in mind? Releasing 3.0 and then nothing
| until 3.2?

Yes, except for 3.0.x releases that fix regressions or other truly
egregious bugs that are relatively safe to fix.

At the same time, I'd like to see more frequent releases.

What is the problem with that?

jwe