Re: release 3.2.1

[Daniel J Sebald]

Jaroslav Hajek wrote:
> On Fri, Jul 3, 2009 at 2:16 PM, Jaroslav Hajek<address@hidden> wrote:
>
> > hello,
> >
> > The Octave 3.2.1 semi-official tarballs are available at
> > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> >
> > We have 82 patches (mostly bug and doc fixes) since the 3.2.0 release.
> > I sincerely thank all contributors and testers for their valuable
> > work.
> > If your favorite bug was not fixed, don't give up hope; Octave is going on :)
> >
> > John, please upload the tarballs to the GNU FTP site.
> >
> > free computing, free society!
>
>
> OK, so hold up the fanfares; the release is flawed and should not be
> used. I've removed the tarballs. See this thread:
> http://www.nabble.com/Bug-in-octave-3.2.x-with-custom-atlas-multithread-td24319610.html
> In short, any use of unwind_protect can cause a segfault (depending on
> calling sequences).
>
> The development version does not suffer from this problem; it's caused
> by a special patch created (by me) for 3.2.x rather than transplanting
> from the development version to avoid breaking ABI compatibility.
>
> This is similar to the issue of 3.0.4 - a very serious bug was
> reported very shortly after the release. Also, the bug was caused by a
> patch specialized for the stable branch to avoid breaking the ABI.
>
> Since this is the second time I've managed to produce a flawed
> release, I think I'm doing a poor job as the stable branch manager,
> and it's time for a change. Who wants to take on the role?

I think to support the branching paradigm we need a better organized team, 
possibly more bug reporting / tracking tools, and some type of beta schedule.  
One has to resist the desire to get new features to market ASAP, and instead 
set versions aside so that the whole group can test-run the version over a 
month.  Just let the developers site know there is a new release candidate for 
beta testing.  Any bugs could then be entered into a bug tracker (which we 
don't have) for the particular version.  Without that, one or two release 
versions, a developer version...and soon it is too much for any one person to 
keep track of.  If it were a smaller project, perhaps, but not one this size.

Also, there are certain hunks of code that are "tricky programming" and should 
be modified only long before a release.  unwind_protect is one of those.  Stacks, 
recursions, interrupts, and such have a lot of paths and conditions that are easy to 
overlook.

Dan