Bug reports for for versions < 5.1.0

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug reports for for versions < 5.1.0

Rik-4
All,

How should we handle bug reports for versions of Octave that are now
deprecated (< 5.1.0)?  I'm not thinking of reports which identify a
particular missing feature in Octave.  Instead, there seem to be a lot of
reports about issues which have since been fixed and are tied only to a
specific version (for example, slow start-up of the GUI on Windows in
4.4.0).  My proposal would be to close them all as some distros do when a
version becomes obsolete and have users file a new bug report against a new
version of Octave if the behavior can still be found.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Bug reports for for versions < 5.1.0

Mike Miller-4
On Tue, Feb 26, 2019 at 09:16:52 -0800, Rik wrote:
> How should we handle bug reports for versions of Octave that are now
> deprecated (< 5.1.0)?  I'm not thinking of reports which identify a
> particular missing feature in Octave.  Instead, there seem to be a lot of
> reports about issues which have since been fixed and are tied only to a
> specific version (for example, slow start-up of the GUI on Windows in
> 4.4.0).  My proposal would be to close them all as some distros do when a
> version becomes obsolete and have users file a new bug report against a new
> version of Octave if the behavior can still be found.

Yeah, if a bug is clearly fixed in 5.1, it should definitely be closed
as fixed. I think that's what we've always done.

If it's not clear whether it's been fixed or not, I would re-tag it as
5.1.0 or dev, ask for someone to test it again in the current version,
and close if there is no reply after several weeks.

I just re-tagged a bunch of open unfixed 5.0.x bugs against either 5.1.0
or dev, depending on whether they seem like suitable stable fixes or
development tasks.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug reports for for versions < 5.1.0

John W. Eaton
Administrator
On 2/26/19 12:42 PM, Mike Miller wrote:

> On Tue, Feb 26, 2019 at 09:16:52 -0800, Rik wrote:
>> How should we handle bug reports for versions of Octave that are now
>> deprecated (< 5.1.0)?  I'm not thinking of reports which identify a
>> particular missing feature in Octave.  Instead, there seem to be a lot of
>> reports about issues which have since been fixed and are tied only to a
>> specific version (for example, slow start-up of the GUI on Windows in
>> 4.4.0).  My proposal would be to close them all as some distros do when a
>> version becomes obsolete and have users file a new bug report against a new
>> version of Octave if the behavior can still be found.
>
> Yeah, if a bug is clearly fixed in 5.1, it should definitely be closed
> as fixed. I think that's what we've always done.

Yes, I agree, even if it is not fixed in the version (or bug fix release
for the version) listed in the bug tracker.  As I see it, that number is
present to help us identify and reproduce the bug.  It should not
represent an expectation or promise to fix the bug in that release series.

Also, it seems satisfying to close old reports and try to reduce the
overall number of open reports, but I also don't want to do that unless
they really are issues that we won't be fixing or the reports have
insufficient information.  I don't want to close valid reports, even if
they are years old.

> If it's not clear whether it's been fixed or not, I would re-tag it as
> 5.1.0 or dev, ask for someone to test it again in the current version,
> and close if there is no reply after several weeks.

If you can reproduce it with the current sources, then yes, I'd
definitely change the version identifier to "dev".

If it's not clear that a bug has been fixed, when does that typically
happen?  When the OS is something you don't have?  Or maybe it is due to
library dependencies?  I'm not sure what to do with the Octave version
number in the report in that case.

> I just re-tagged a bunch of open unfixed 5.0.x bugs against either 5.1.0
> or dev, depending on whether they seem like suitable stable fixes or
> development tasks.

Thanks.

jwe




Reply | Threaded
Open this post in threaded view
|

Re: Bug reports for for versions < 5.1.0

Mike Miller-4
On Tue, Feb 26, 2019 at 17:45:34 -0500, John W. Eaton wrote:

> On 2/26/19 12:42 PM, Mike Miller wrote:
> > If it's not clear whether it's been fixed or not, I would re-tag it as
> > 5.1.0 or dev, ask for someone to test it again in the current version,
> > and close if there is no reply after several weeks.
>
> If you can reproduce it with the current sources, then yes, I'd definitely
> change the version identifier to "dev".
>
> If it's not clear that a bug has been fixed, when does that typically
> happen?  When the OS is something you don't have?  Or maybe it is due to
> library dependencies?  I'm not sure what to do with the Octave version
> number in the report in that case.
Yeah, many are when the bug is specific to another OS. Sometimes the bug
is very complex or involves software or a desktop environment or
something else that I don't have easy access to.

As an example, I just updated https://savannah.gnu.org/bugs/?50351 from
4.0.0 to dev and asked the OP whether the bug is still present or
relevant. If there is no response within the next weeks to months, we
should close this as invalid. This bug is highly specific to the Intel
compiler and is against a version of Octave from 3 years ago. If the OP
is no longer engaged I don't see any way for the bug to progress.

As another example, I updated https://savannah.gnu.org/bugs/?55031 from
4.0.0 to dev, but I have nothing to add. It looks to me like it might be
a machine precision issue, or maybe an expected discontinuity. The OP
asserts that there is a problem, but the result is a plot. I honestly
can't tell from looking at a plot whether there is a problem or not.

--
mike

signature.asc (849 bytes) Download Attachment