Re: Criteria for identifying must-fix bugs

[Rik]

On 10/10/2013 07:32 AM, Reza Housseini wrote:

On Wed, Oct 9, 2013 at 11:45 PM, Michael D. Godfrey <address@hidden> wrote:

On 10/09/2013 01:47 PM, Rik wrote:

Previously, we used the criteria of any bug report with a Severity >= 4 or
any Item Group == Regression.  For starters, I have put those up on the 3.8
bug fix list (http://wiki.octave.org/3.8_Bug_Fix_List).

Another bug that should be added is:

#33748: plotyy: only subset of data series plotted in FLTK

This bug report came about due to the OpenGL restriction to reals.  There are, I think,
at least three choices for the release:

1. Fix the "real" problem by rescaling.

This is the right thing to do, but probably beyond what we can implement just now.

2. Test the data for values outside "real."  Then, issue a warning and, maybe,
    replace the outside values with NaN, or something that would avoid the user
    misinterpreting the plotted output.

Could do this, but I like the next option better.

3. Take an error return and do not generate a plot.  This is safest action.

Simple and safe.  Probably the best we can do right now.  I'll file a bug report about it.  And, for implementation, it isn't necessary to give the warning if the axis scales are logarithmic since there is plenty of room then.

And what about https://savannah.gnu.org/bugs/?func=detailitem&item_id=40121?

I've purged the bug list of the "Crash" reports which weren't really crashes.  This still leaves 23 instances which I posted to the Bug Fix List (http://wiki.octave.org/3.8_Bug_Fix_List).  I've marked them all as nice to fix, but not required to fix, before the next release.  If someone else would like to go through this smaller list and identify items they feel really should be in the required category that would be helpful.  For bug #40121, I was the original reporter and the case of using dbquit within a graphics callback is obscure enough that I don't think too many people will run into it.  Hence, I don't deem it a must-fix bug before release.

--Rik