|
»
»
Re: release 3.2.1
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
|
|
|
|
Re: release 3.2.1
by Jaroslav Hajek-2
::
Rate this Message:
On Fri, Jul 3, 2009 at 6:55 PM, Jaroslav Hajek<highegg@...> wrote:
> On Fri, Jul 3, 2009 at 2:16 PM, Jaroslav Hajek<highegg@...> 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? > > Forgive me my bitterness, but I'm really disappointed. > > Sorry for all the noise. Please don't use the tarballs (if you already > downloaded them) for packages. Recent RCs also suffer from the bug; > right now I can't check which ones. > > best regards > As a follow-up, I've just committed a fix to the repo; so if anyone is interested in making the release, feel free. I won't be able to do it for the following two weeks. -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz |
|
|
|
|
|
|
|
Re: release 3.2.1
by Daniel J Sebald
::
Rate this Message:
Jaroslav Hajek wrote:
> On Fri, Jul 3, 2009 at 2:16 PM, Jaroslav Hajek<highegg@...> 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 |
|
|
|
|
The bug is also present in octave 3.0.5 and it depends on the version of lapack % program bug.m clear all; k=12 rm = rand(k,k); im = i*rand(k,k); M =[rm+im]; eig(M) with k=11 works fine see (this is the output of octave 3.0.5) k = 12 ** On entry to ZGEEV parameter number 5 had an illegal value error: exception encountered in Fortran subroutine zgeev_ error: unrecoverable error in zgeev error: near line 9 of file `bug.m' I found the same bug report here http://www.nabble.com/bug_report-td24074298.html I used lapack3.2 compiled in this way FORTRAN = gfortran -fomit-frame-pointer -mfpmath=387 -falign-loops=4 -fPIC -m64 OPTS = -O2 DRVOPTS = $(OPTS) NOOPT = -O0 LOADER = gfortran Hope this helps Bests regards Riccardo Corradini --- Ven 3/7/09, Jaroslav Hajek <highegg@...> ha scritto:
|
Re: release 3.2.1
by Riccardo Corradini
::
Rate this Message:
| Dear stuff, I may confirm that the bug doesn't persist on octave 3.2.x using lapack 3.1.1 and linking multithread ATLAS 3.8.2 and suitesparse 3.4.0 etc..with this version 3.1.1. clear all; k=70 rm = rand(k,k); im = i*rand(k,k); M =[rm+im]; eig(M) octave:5> bug k = 70 ans = 34.595137 + 35.003166i -2.167966 - 2..730927i 2.683064 - 1.900657i 1.979373 - 2.472401i 1.178912 - 2.827986i -2.860170 - 1.533597i -1.278215 - 2.763166i -0.491053 - 2.941520i 0.520176 - 2.896501i -2.960968 + 1.551305i 1.474251 + 2.878508i -0.985561 + 3.205582i 0.949570 + 3.136731i 1.736646 + 2.600285i 2.177071 + 2.136767i -2.328299 - 1.938764i -0.593303 + 3.140876i -3.047102 - 0.601651i -1.476843 + 2.605897i -3.054729 + 0.344304i 2.902470 - 1.091961i -2.945894 + 0.033653i -2.188876 - 1.253901i 0.315834 - 2.573156i -2.664956 - 0.268846i -0.446686 - 2.320919i -1.341214 - 1.998793i -1.932610 + 1.934674i -1.615172 - 1.720390i -2.349678 + 1.321243i 2.955040 - 0.005761i 2..745320 - 0.583099i 2.797037 + 0.080460i 2.282558 - 1.250512i 2.284922 + 1.334640i 1.750200 - 1.592420i -0.608666 + 2.665563i 0..494899 + 2.678137i 1.238442 + 2.027985i -1.072397 + 2.093937i 0.284871 + 2.394743i 1.335571 + 1.608872i 0.899077 - 1.904376i 0.093908 + 2.294564i 2.129679 + 0.812796i 2.130816 + 0.462608i -1.986207 + 1.122237i 1.958445 + 0.238566i 1.069674 - 1.486838i 1.729207 - 0.401135i -1.353499 + 1.208122i -1.996072 - 0.015079i -1.261178 - 1.259285i -1.691011 - 0.475858i 0.195023 + 1.601117i -1.258667 + 0.915337i -1.348994 + 0.479200i 1.155294 - 0.633605i 0.347096 - 1.348782i 1.305510 + 0.084355i -0.432691 - 1.156473i 0.824667 + 0.675111i -0..118540 + 1.016295i -0.644870 - 0.623766i -0.964274 - 0.224641i 0.379883 + 0.686498i 0.532738 + 0.052474i 0.022758 - 0.474934i -0.391990 + 0.071362i -0.105894 - 0.033903i Bests Riccardo Corradini --- Lun 6/7/09, Daniel J Sebald <daniel.sebald@...> ha scritto:
|
Re: release 3.2.1
by Robert T. Short
::
Rate this Message:
Is there to be no comment on this at all? Both Daniel and I have made
the same comments for the same reasons and probably because we have both
experienced problems like this before. It isn't that Jaroslav is doing
a bad job, but rather that the process (or rather lack of process) is
guaranteed to have significant problems.
Bob
>
> 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
>
>
the same comments for the same reasons and probably because we have both
experienced problems like this before. It isn't that Jaroslav is doing
a bad job, but rather that the process (or rather lack of process) is
guaranteed to have significant problems.
Bob
>
> 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
>
>
release 3.2.1
by jwleblan
::
Rate this Message:
Forgot to forward again... forgive the noob : )
~Joel
P.S.
Perhaps a forum as well?
---------- Forwarded message ----------
From: Joel LeBlanc <jwleblan@...>
Date: Thu, Jul 9, 2009 at 7:34 PM
Subject: Re: release 3.2.1
To: "Robert T. Short" <octave@...>
Agreed. A bug tracker would be nice (Trac... or the like).
From: Joel LeBlanc <jwleblan@...>
Date: Thu, Jul 9, 2009 at 7:34 PM
Subject: Re: release 3.2.1
To: "Robert T. Short" <octave@...>
Agreed. A bug tracker would be nice (Trac... or the like).
It would be nice to have anything labeled X.Y.Z to be "stable". Which is to say, it should go through some type of beta.
~Joel
On Thu, Jul 9, 2009 at 5:14 PM, Robert T. Short <octave@...> wrote:
Is there to be no comment on this at all? Both Daniel and I have made the same comments for the same reasons and probably because we have both experienced problems like this before. It isn't that Jaroslav is doing a bad job, but rather that the process (or rather lack of process) is guaranteed to have significant problems.
Bob
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
Re: release 3.2.1
by Søren Hauberg
::
Rate this Message:
tor, 09 07 2009 kl. 14:14 -0700, skrev Robert T. Short:
> Is there to be no comment on this at all? Both Daniel and I have made
> the same comments for the same reasons and probably because we have both
> experienced problems like this before. It isn't that Jaroslav is doing
> a bad job, but rather that the process (or rather lack of process) is
> guaranteed to have significant problems.
Well, I agree that Jaroslav is _not_ doing a bad job. Release management
is just surprisingly hard (I've managed to screw up every single
Octave-Forge release I've ever made...).
I haven't commented on the suggestions related to how to fix this, as it
seems like what is being asked for is more man-power. Basically, we need
a set of beta testers that are willing to use release candidates for a
couple of months before that final release is made. The big problem with
this is that currently when a new release is branched, development still
goes on in the main branch. Personally, I tend to run a version that is
a recent checkout from the main branch, so I qualify for being a beta
tester. However, if development is going on in the main branch, then I'd
prefer to run that rather than the soon-to-be-released-beta-branch. I
mean, if I'm gonna run development versions, then I might as well live
on the bleeding edge, right?
Anyway, my point is just that to improve release quality, we need more
testers. We actually have a bunch of such testers, but they all tend to
run the latest development version rather than the latest release
candidate. The only solution I see (as long as we don't have more
man-power), is to only have one branch of development.
Søren
> Is there to be no comment on this at all? Both Daniel and I have made
> the same comments for the same reasons and probably because we have both
> experienced problems like this before. It isn't that Jaroslav is doing
> a bad job, but rather that the process (or rather lack of process) is
> guaranteed to have significant problems.
Well, I agree that Jaroslav is _not_ doing a bad job. Release management
is just surprisingly hard (I've managed to screw up every single
Octave-Forge release I've ever made...).
I haven't commented on the suggestions related to how to fix this, as it
seems like what is being asked for is more man-power. Basically, we need
a set of beta testers that are willing to use release candidates for a
couple of months before that final release is made. The big problem with
this is that currently when a new release is branched, development still
goes on in the main branch. Personally, I tend to run a version that is
a recent checkout from the main branch, so I qualify for being a beta
tester. However, if development is going on in the main branch, then I'd
prefer to run that rather than the soon-to-be-released-beta-branch. I
mean, if I'm gonna run development versions, then I might as well live
on the bleeding edge, right?
Anyway, my point is just that to improve release quality, we need more
testers. We actually have a bunch of such testers, but they all tend to
run the latest development version rather than the latest release
candidate. The only solution I see (as long as we don't have more
man-power), is to only have one branch of development.
Søren
Re: release 3.2.1
by Thomas Weber-8
::
Rate this Message:
On Fri, Jul 10, 2009 at 09:49:44AM +0200, Søren Hauberg wrote:
> I haven't commented on the suggestions related to how to fix this, as it
> seems like what is being asked for is more man-power. Basically, we need
> a set of beta testers that are willing to use release candidates for a
> couple of months before that final release is made.
No one will be doing this. Let's get some numbers: how many of you run
Octave proper? How many have Octave-Forge packages that need a
re-compile for a new Octave release? How much time do you want to spend
on testing a release?
I know for myself, that I consider "make check" to be the one and only
test. It's easy, integrated and gives immediate feedback. It can be run
on architectures I don't have direct access to and is reproducible.
> Anyway, my point is just that to improve release quality, we need more
> testers. We actually have a bunch of such testers, but they all tend to
> run the latest development version rather than the latest release
> candidate. The only solution I see (as long as we don't have more
> man-power), is to only have one branch of development.
I dare say that we need a different handling of bug-fixes. I really mean
the fixes here. Let's take the current issue as example:
=======================================================================
--- a/src/pt-eval.cc Wed Jun 24 07:40:21 2009 +0200
+++ b/src/pt-eval.cc Fri Jul 03 18:59:07 2009 +0200
@@ -986,6 +986,8 @@
unwind_protect::discard ();
else
unwind_protect::run ();
+
+ unwind_protect::run ();
}
void
=======================================================================
That's the fix for the current issue. Will this fix prevent a similar
problem from getting by unnoticed? No, there's no test for it in "make
check".
So, I'd say we don't need more testers, but more tests.
Thomas
> I haven't commented on the suggestions related to how to fix this, as it
> seems like what is being asked for is more man-power. Basically, we need
> a set of beta testers that are willing to use release candidates for a
> couple of months before that final release is made.
No one will be doing this. Let's get some numbers: how many of you run
Octave proper? How many have Octave-Forge packages that need a
re-compile for a new Octave release? How much time do you want to spend
on testing a release?
I know for myself, that I consider "make check" to be the one and only
test. It's easy, integrated and gives immediate feedback. It can be run
on architectures I don't have direct access to and is reproducible.
> Anyway, my point is just that to improve release quality, we need more
> testers. We actually have a bunch of such testers, but they all tend to
> run the latest development version rather than the latest release
> candidate. The only solution I see (as long as we don't have more
> man-power), is to only have one branch of development.
I dare say that we need a different handling of bug-fixes. I really mean
the fixes here. Let's take the current issue as example:
=======================================================================
--- a/src/pt-eval.cc Wed Jun 24 07:40:21 2009 +0200
+++ b/src/pt-eval.cc Fri Jul 03 18:59:07 2009 +0200
@@ -986,6 +986,8 @@
unwind_protect::discard ();
else
unwind_protect::run ();
+
+ unwind_protect::run ();
}
void
=======================================================================
That's the fix for the current issue. Will this fix prevent a similar
problem from getting by unnoticed? No, there's no test for it in "make
check".
So, I'd say we don't need more testers, but more tests.
Thomas
Re: release 3.2.1
by Søren Hauberg
::
Rate this Message:
fre, 10 07 2009 kl. 22:19 +0200, skrev Thomas Weber:
> On Fri, Jul 10, 2009 at 09:49:44AM +0200, Søren Hauberg wrote:
> > I haven't commented on the suggestions related to how to fix this, as it
> > seems like what is being asked for is more man-power. Basically, we need
> > a set of beta testers that are willing to use release candidates for a
> > couple of months before that final release is made.
>
> No one will be doing this.
Agreed; at least assuming we do things as we do now. I do think (that's
my impression, but I don't have any numbers to back it up) we have a
bunch of people that run development sources, and these people are kinda
beta testers. The difficulties appear when we branch for a stable
release. At that point we have two development branches, meaning about
half of the people running development versions will be using the
version about to be released (I actually think it's less than half). So,
even less beta testers. My suggestion: don't branch the development
version.
> How much time do you want to spend on testing a release?
I don't want to spend _any_ time testing a release, because that's
really boring. However, I don't mind using a pre-release for my actual
work (I do this), so I could easily be a beta tester for a month or two.
This is, however, much harder when there are two development branches to
choose from.
> So, I'd say we don't need more testers, but more tests.
Tests are good, and everybody agrees we need more of those. But I
honestly don't think tests can catch everything (that would require an
enormous amount of tests). I think we need to run actual programs, and
not just unit tests.
Søren
> On Fri, Jul 10, 2009 at 09:49:44AM +0200, Søren Hauberg wrote:
> > I haven't commented on the suggestions related to how to fix this, as it
> > seems like what is being asked for is more man-power. Basically, we need
> > a set of beta testers that are willing to use release candidates for a
> > couple of months before that final release is made.
>
> No one will be doing this.
Agreed; at least assuming we do things as we do now. I do think (that's
my impression, but I don't have any numbers to back it up) we have a
bunch of people that run development sources, and these people are kinda
beta testers. The difficulties appear when we branch for a stable
release. At that point we have two development branches, meaning about
half of the people running development versions will be using the
version about to be released (I actually think it's less than half). So,
even less beta testers. My suggestion: don't branch the development
version.
> How much time do you want to spend on testing a release?
I don't want to spend _any_ time testing a release, because that's
really boring. However, I don't mind using a pre-release for my actual
work (I do this), so I could easily be a beta tester for a month or two.
This is, however, much harder when there are two development branches to
choose from.
> So, I'd say we don't need more testers, but more tests.
Tests are good, and everybody agrees we need more of those. But I
honestly don't think tests can catch everything (that would require an
enormous amount of tests). I think we need to run actual programs, and
not just unit tests.
Søren
Re: release 3.2.1
by Robert T. Short
::
Rate this Message:
Søren Hauberg wrote:
So are you suggesting that we don't have a stable branch? I guess that is one way! It certainly works for the developer community but not for the general user community. Is it not a goal to provide a solid package for non-developer users?
Bob
Release management IS hard. It is the Achilles heel of many, many software systems.tor, 09 07 2009 kl. 14:14 -0700, skrev Robert T. Short:Is there to be no comment on this at all? Both Daniel and I have made the same comments for the same reasons and probably because we have both experienced problems like this before. It isn't that Jaroslav is doing a bad job, but rather that the process (or rather lack of process) is guaranteed to have significant problems.Well, I agree that Jaroslav is _not_ doing a bad job. Release management is just surprisingly hard (I've managed to screw up every single Octave-Forge release I've ever made...). I haven't commented on the suggestions related to how to fix this, as it seems like what is being asked for is more man-power. Basically, we need a set of beta testers that are willing to use release candidates for a couple of months before that final release is made. The big problem with this is that currently when a new release is branched, development still goes on in the main branch. Personally, I tend to run a version that is a recent checkout from the main branch, so I qualify for being a beta tester. However, if development is going on in the main branch, then I'd prefer to run that rather than the soon-to-be-released-beta-branch. I mean, if I'm gonna run development versions, then I might as well live on the bleeding edge, right? Anyway, my point is just that to improve release quality, we need more testers. We actually have a bunch of such testers, but they all tend to run the latest development version rather than the latest release candidate. The only solution I see (as long as we don't have more man-power), is to only have one branch of development. Søren
So are you suggesting that we don't have a stable branch? I guess that is one way! It certainly works for the developer community but not for the general user community. Is it not a goal to provide a solid package for non-developer users?
Bob
Re: release 3.2.1
by Daniel J Sebald
::
Rate this Message:
Søren Hauberg wrote:
> tor, 09 07 2009 kl. 14:14 -0700, skrev Robert T. Short:
>
>>Is there to be no comment on this at all? Both Daniel and I have made
>>the same comments for the same reasons and probably because we have both
>>experienced problems like this before. It isn't that Jaroslav is doing
>>a bad job, but rather that the process (or rather lack of process) is
>>guaranteed to have significant problems.
>
>
> Well, I agree that Jaroslav is _not_ doing a bad job. Release management
> is just surprisingly hard (I've managed to screw up every single
> Octave-Forge release I've ever made...).
That's what I'm assuming.
> I haven't commented on the suggestions related to how to fix this, as it
> seems like what is being asked for is more man-power. Basically, we need
> a set of beta testers that are willing to use release candidates for a
> couple of months before that final release is made. The big problem with
> this is that currently when a new release is branched, development still
> goes on in the main branch. Personally, I tend to run a version that is
> a recent checkout from the main branch, so I qualify for being a beta
> tester. However, if development is going on in the main branch, then I'd
> prefer to run that rather than the soon-to-be-released-beta-branch. I
> mean, if I'm gonna run development versions, then I might as well live
> on the bleeding edge, right?
Bleeding edge is good (and fun), but as Octave has gained features I've become content to be slightly behind bleeding edge. I'd be alright working with a release candidate for a month or two. As someone else pointed out, a modest group of people using the software is fine as a "beta" test. People tend to have slight variation in programming styles that might challenge what the original programmer may have overlooked.
> Anyway, my point is just that to improve release quality, we need more
> testers. We actually have a bunch of such testers, but they all tend to
> run the latest development version rather than the latest release
> candidate. The only solution I see (as long as we don't have more
> man-power), is to only have one branch of development.
I'm tending to agree with that.
Seeing the drop in activity over the past half month, I think that a good release schedule for major releases would be to work toward a candidate version near the end of May or mid June. Hold off cutting edge features in summer when activity drops due to vacation/holiday, concentrating instead on bug fixes. How about the major release mid to late August? With Mercurial's capabilities, I'm understanding that people can queue up their changes for a few weeks. After the release, there'll be a flood of change sets.
Dan
> tor, 09 07 2009 kl. 14:14 -0700, skrev Robert T. Short:
>
>>Is there to be no comment on this at all? Both Daniel and I have made
>>the same comments for the same reasons and probably because we have both
>>experienced problems like this before. It isn't that Jaroslav is doing
>>a bad job, but rather that the process (or rather lack of process) is
>>guaranteed to have significant problems.
>
>
> Well, I agree that Jaroslav is _not_ doing a bad job. Release management
> is just surprisingly hard (I've managed to screw up every single
> Octave-Forge release I've ever made...).
That's what I'm assuming.
> I haven't commented on the suggestions related to how to fix this, as it
> seems like what is being asked for is more man-power. Basically, we need
> a set of beta testers that are willing to use release candidates for a
> couple of months before that final release is made. The big problem with
> this is that currently when a new release is branched, development still
> goes on in the main branch. Personally, I tend to run a version that is
> a recent checkout from the main branch, so I qualify for being a beta
> tester. However, if development is going on in the main branch, then I'd
> prefer to run that rather than the soon-to-be-released-beta-branch. I
> mean, if I'm gonna run development versions, then I might as well live
> on the bleeding edge, right?
Bleeding edge is good (and fun), but as Octave has gained features I've become content to be slightly behind bleeding edge. I'd be alright working with a release candidate for a month or two. As someone else pointed out, a modest group of people using the software is fine as a "beta" test. People tend to have slight variation in programming styles that might challenge what the original programmer may have overlooked.
> Anyway, my point is just that to improve release quality, we need more
> testers. We actually have a bunch of such testers, but they all tend to
> run the latest development version rather than the latest release
> candidate. The only solution I see (as long as we don't have more
> man-power), is to only have one branch of development.
I'm tending to agree with that.
Seeing the drop in activity over the past half month, I think that a good release schedule for major releases would be to work toward a candidate version near the end of May or mid June. Hold off cutting edge features in summer when activity drops due to vacation/holiday, concentrating instead on bug fixes. How about the major release mid to late August? With Mercurial's capabilities, I'm understanding that people can queue up their changes for a few weeks. After the release, there'll be a flood of change sets.
Dan
Re: release 3.2.1
by Daniel J Sebald
::
Rate this Message:
Joel LeBlanc wrote:
> Forgot to forward again... forgive the noob : )
> ~Joel
>
> P.S.
> Perhaps a forum as well?
>
> ---------- Forwarded message ----------
> From: Joel LeBlanc <jwleblan@...>
> Date: Thu, Jul 9, 2009 at 7:34 PM
> Subject: Re: release 3.2.1
> To: "Robert T. Short" <octave@...>
>
>
> Agreed. A bug tracker would be nice (Trac... or the like).
Yes. I'd say that trying that before trying release branches would be good. Perhaps not every bug in the development realm needs tracking, but its good for submitted bugs pertaining to main releases and a bug that a developer can't address immediately such that it isn't forgotten.
Dan
> Forgot to forward again... forgive the noob : )
> ~Joel
>
> P.S.
> Perhaps a forum as well?
>
> ---------- Forwarded message ----------
> From: Joel LeBlanc <jwleblan@...>
> Date: Thu, Jul 9, 2009 at 7:34 PM
> Subject: Re: release 3.2.1
> To: "Robert T. Short" <octave@...>
>
>
> Agreed. A bug tracker would be nice (Trac... or the like).
Yes. I'd say that trying that before trying release branches would be good. Perhaps not every bug in the development realm needs tracking, but its good for submitted bugs pertaining to main releases and a bug that a developer can't address immediately such that it isn't forgotten.
Dan
Re: release 3.2.1
by Søren Hauberg
::
Rate this Message:
fre, 10 07 2009 kl. 15:06 -0700, skrev Robert T. Short:
> So are you suggesting that we don't have a stable branch? I guess
> that is one way! It certainly works for the developer community but
> not for the general user community. Is it not a goal to provide a
> solid package for non-developer users?
Not quite what I meant. Right now we have two branches:
* The 3.2.x stable branch. This is the one most users are on.
* The 3.3.x development branch. This is the one developers are mostly
using; it's the 'fun' branch.
Some time before 3.4.0 is to be released then we will have the following
branches (assuming we use the same approach as we do now)
* The 3.2.x stable branch.
* The 3.4.0-beta branch, where only bog fixes are allowed.
* The 3.5.x development branch, where the fun stuff happens.
My suggestion was not to make the 3.5.x branch. This will probably slow
down development somewhat, but it will ensure that people on the
development branch serves as beta testers. This was essentially how
things were done before the switch to Mercurial.
Søren
> So are you suggesting that we don't have a stable branch? I guess
> that is one way! It certainly works for the developer community but
> not for the general user community. Is it not a goal to provide a
> solid package for non-developer users?
Not quite what I meant. Right now we have two branches:
* The 3.2.x stable branch. This is the one most users are on.
* The 3.3.x development branch. This is the one developers are mostly
using; it's the 'fun' branch.
Some time before 3.4.0 is to be released then we will have the following
branches (assuming we use the same approach as we do now)
* The 3.2.x stable branch.
* The 3.4.0-beta branch, where only bog fixes are allowed.
* The 3.5.x development branch, where the fun stuff happens.
My suggestion was not to make the 3.5.x branch. This will probably slow
down development somewhat, but it will ensure that people on the
development branch serves as beta testers. This was essentially how
things were done before the switch to Mercurial.
Søren
Re: release 3.2.1
by Thomas Weber-8
::
Rate this Message:
On Fri, Jul 10, 2009 at 11:05:30PM +0200, Søren Hauberg wrote:
> > So, I'd say we don't need more testers, but more tests.
>
> Tests are good, and everybody agrees we need more of those. But I
> honestly don't think tests can catch everything (that would require an
> enormous amount of tests). I think we need to run actual programs, and
> not just unit tests.
I disagree here. If you add a test for every bug you fix, that gives you
coverage where it's needed. It's also not necessarily more work, as you
already know how to trigger a bug.
Thomas
> > So, I'd say we don't need more testers, but more tests.
>
> Tests are good, and everybody agrees we need more of those. But I
> honestly don't think tests can catch everything (that would require an
> enormous amount of tests). I think we need to run actual programs, and
> not just unit tests.
I disagree here. If you add a test for every bug you fix, that gives you
coverage where it's needed. It's also not necessarily more work, as you
already know how to trigger a bug.
Thomas
Re: release 3.2.1
by Søren Hauberg
::
Rate this Message:
lør, 11 07 2009 kl. 17:01 +0200, skrev Thomas Weber:
> On Fri, Jul 10, 2009 at 11:05:30PM +0200, Søren Hauberg wrote:
> > > So, I'd say we don't need more testers, but more tests.
> >
> > Tests are good, and everybody agrees we need more of those. But I
> > honestly don't think tests can catch everything (that would require an
> > enormous amount of tests). I think we need to run actual programs, and
> > not just unit tests.
>
> I disagree here. If you add a test for every bug you fix, that gives you
> coverage where it's needed. It's also not necessarily more work, as you
> already know how to trigger a bug.
More tests would be a good thing, and I agree that more effort should be
put into turning bug reports into tests. I just don't think tests alone
will do.
Søren
> On Fri, Jul 10, 2009 at 11:05:30PM +0200, Søren Hauberg wrote:
> > > So, I'd say we don't need more testers, but more tests.
> >
> > Tests are good, and everybody agrees we need more of those. But I
> > honestly don't think tests can catch everything (that would require an
> > enormous amount of tests). I think we need to run actual programs, and
> > not just unit tests.
>
> I disagree here. If you add a test for every bug you fix, that gives you
> coverage where it's needed. It's also not necessarily more work, as you
> already know how to trigger a bug.
More tests would be a good thing, and I agree that more effort should be
put into turning bug reports into tests. I just don't think tests alone
will do.
Søren
Release process (was release 3.2.1)
by Robert T. Short
::
Rate this Message:
OK. This makes more sense to me.fre, 10 07 2009 kl. 15:06 -0700, skrev Robert T. Short:So are you suggesting that we don't have a stable branch? I guess that is one way! It certainly works for the developer community but not for the general user community. Is it not a goal to provide a solid package for non-developer users?Not quite what I meant. Right now we have two branches: * The 3.2.x stable branch. This is the one most users are on. * The 3.3.x development branch. This is the one developers are mostly using; it's the 'fun' branch. Some time before 3.4.0 is to be released then we will have the following branches (assuming we use the same approach as we do now) * The 3.2.x stable branch. * The 3.4.0-beta branch, where only bog fixes are allowed. * The 3.5.x development branch, where the fun stuff happens. My suggestion was not to make the 3.5.x branch. This will probably slow down development somewhat, but it will ensure that people on the development branch serves as beta testers. This was essentially how things were done before the switch to Mercurial. Søren
The problem I am having is calling the 3.2.x branch stable. It isn't stable. After it has existed for a while it should become stable, but it isn't stable yet.
Here is my view of the current release process:
- We create a snapshot of the development sources.
- We apply patches for a few days
- We call the release stable.
The problem is that there always seem to be dozens of patches in those few days in the second step, so the release is NOT stable. There was some discussion of beta testers, but what is occurring is that we never even get out of ALPHA test before we call it stable. Here is what I would propose.
- Clearly define what the release criteria are. I think Jaroslav plans this
to be simply every two months. I think that is too fast, but if that is the
criteria, stick by it.
- Freeze the current stable version forever - no more bug fixes, patches, etc.
- Snapshot the development branch into the "stable" source tree. It isn't
stable yet of course, but the objective is to stabilize it. For now it is
a "testing" or "alpha" version.
- Apply bug fixes (no new features) for several weeks - until the bug fixes
from the developer community slow down to a fairly low rate. This is
*alpha* testing.
I would strongly encourage ALL developers to install the testing version
during this period. Like Søren and probably many of the rest of you, I
tend to install a fairly recent tip for my own work, but there is little
penalty to using this version for a few weeks.
During this time, do your work with it. Run scripts, functions, etc., but
all you need to do is make sure *your* stuff works. I think this will
actually get a lot of code coverage.
- When the bug rate drops to a reasonable level, release the testing version
to the greater user community as a beta version. The developers should
probably move on to the tip at this point so the tip is getting the some
scrutiny.
Note that with this model there are only two active branches at any time, which is what Søren was suggesting, I think. Also, the only significant difference between this model and the current model is that we wait until the bugs dwindle before releasing it to the public.
I agree that more tests are essential, but I also agree with Søren that tests are not enough. People have to use the software to do their jobs. If we do this, the only extra effort involved is making sure you are using the "testing" version rather than the tip.
Bob
Re: Release process (was release 3.2.1)
by Tatsuro MATSUOKA-2
::
Rate this Message:
Hello
--- "Robert T. Short" wrote:
>
> ---------------------------------
> S淡ren Hauberg wrote:
> fre, 10 07 2009 kl. 15:06 -0700, skrev Robert T. Short:
>
> So are you suggesting that we don't have a stable branch? I guessthat is one way! It certainly
> works for the developer community butnot for the general user community. Is it not a goal to
> provide asolid package for non-developer users?
>
> Not quite what I meant. Right now we have two branches: * The 3.2.x stable branch. This is the
> one most users are on. * The 3.3.x development branch. This is the one developers are mostly
> using; it's the 'fun' branch.Some time before 3.4.0 is to be released then we will have the
> followingbranches (assuming we use the same approach as we do now) * The 3.2.x stable branch.
> * The 3.4.0-beta branch, where only bog fixes are allowed. * The 3.5.x development branch,
> where the fun stuff happens.My suggestion was not to make the 3.5.x branch. This will probably
> slowdown development somewhat, but it will ensure that people on thedevelopment branch serves as
> beta testers. This was essentially howthings were done before the switch to Mercurial.S淡ren
> OK.� This makes more sense to me.
>
> The problem I am having is calling the 3.2.x branch stable.� It isn'tstable.� After ithas
> existed for a while it should become stable, butit isn't stable yet.
First I appreciate Jaroslav for his extensive works on octave.
I also think so. I feel that octave 3.2.x in the future will be suitable called stable, however
current release 3.2.0 is too fast to be call stable.
During octave releases were 2.x.x
2.9.x was development release.
2.1.x was testing release
2.0.c was stable release but obsolate
I feel that the above is reasonable for me. The previous model is not so far from what Robert proposed
Regards
Tatsuro
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
--- "Robert T. Short" wrote:
>
> ---------------------------------
> S淡ren Hauberg wrote:
> fre, 10 07 2009 kl. 15:06 -0700, skrev Robert T. Short:
>
> So are you suggesting that we don't have a stable branch? I guessthat is one way! It certainly
> works for the developer community butnot for the general user community. Is it not a goal to
> provide asolid package for non-developer users?
>
> Not quite what I meant. Right now we have two branches: * The 3.2.x stable branch. This is the
> one most users are on. * The 3.3.x development branch. This is the one developers are mostly
> using; it's the 'fun' branch.Some time before 3.4.0 is to be released then we will have the
> followingbranches (assuming we use the same approach as we do now) * The 3.2.x stable branch.
> * The 3.4.0-beta branch, where only bog fixes are allowed. * The 3.5.x development branch,
> where the fun stuff happens.My suggestion was not to make the 3.5.x branch. This will probably
> slowdown development somewhat, but it will ensure that people on thedevelopment branch serves as
> beta testers. This was essentially howthings were done before the switch to Mercurial.S淡ren
> OK.� This makes more sense to me.
>
> The problem I am having is calling the 3.2.x branch stable.� It isn'tstable.� After it
> existed for a while it should become stable, butit isn't stable yet.
First I appreciate Jaroslav for his extensive works on octave.
I also think so. I feel that octave 3.2.x in the future will be suitable called stable, however
current release 3.2.0 is too fast to be call stable.
During octave releases were 2.x.x
2.9.x was development release.
2.1.x was testing release
2.0.c was stable release but obsolate
I feel that the above is reasonable for me. The previous model is not so far from what Robert proposed
Regards
Tatsuro
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
Re: release 3.2.1
by Jaroslav Hajek-2
::
Rate this Message:
On Fri, Jul 3, 2009 at 7:02 PM, Jaroslav Hajek<highegg@...> wrote:
> On Fri, Jul 3, 2009 at 6:55 PM, Jaroslav Hajek<highegg@...> wrote:
>> On Fri, Jul 3, 2009 at 2:16 PM, Jaroslav Hajek<highegg@...> 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?
>>
>> Forgive me my bitterness, but I'm really disappointed.
>>
>> Sorry for all the noise. Please don't use the tarballs (if you already
>> downloaded them) for packages. Recent RCs also suffer from the bug;
>> right now I can't check which ones.
>>
>> best regards
>>
>
> As a follow-up, I've just committed a fix to the repo; so if anyone is
> interested in making the release, feel free. I won't be able to do it
> for the following two weeks.
>
Back from vacation, I created the updated tarballs.
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
The only patch added is the following critical fix:
http://hg.tw-math.de/release-3-2-x/rev/bcb3e85add22
Unless there are more critical bugs (I hope not), the release is ready.
John, please upload the tarballs to the official places when you have time to.
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
> On Fri, Jul 3, 2009 at 6:55 PM, Jaroslav Hajek<highegg@...> wrote:
>> On Fri, Jul 3, 2009 at 2:16 PM, Jaroslav Hajek<highegg@...> 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?
>>
>> Forgive me my bitterness, but I'm really disappointed.
>>
>> Sorry for all the noise. Please don't use the tarballs (if you already
>> downloaded them) for packages. Recent RCs also suffer from the bug;
>> right now I can't check which ones.
>>
>> best regards
>>
>
> As a follow-up, I've just committed a fix to the repo; so if anyone is
> interested in making the release, feel free. I won't be able to do it
> for the following two weeks.
>
Back from vacation, I created the updated tarballs.
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
The only patch added is the following critical fix:
http://hg.tw-math.de/release-3-2-x/rev/bcb3e85add22
Unless there are more critical bugs (I hope not), the release is ready.
John, please upload the tarballs to the official places when you have time to.
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
