Re: 3.4 and bug reports

[Rik]

Thomas Weber wrote:
> On Wed, Feb 09, 2011 at 07:44:31PM -0500, John W. Eaton wrote:
>> On  8-Feb-2011, Rik wrote:
>>
>> | How do we want to handle the many reports on the bug tracker which deal
>> | with older versions of Octave?  Many distros, like Fedora, simply go
>> | through and close down the old reports and ask users to re-submit if the
>> | problem persists.  This is mildly rude, but also a big time-saver because a
>> | lot of these problems were with building intermediate development versions
>> | of Octave.  These will have been fixed by the 3.4.0 release, or they would
>> | need to be updated anyways to make it clear that something is still wrong.
>>
>> I don't think it makes sense to close everything just because there is
>> a new release.  But it would be helpful to go back and check old
>> reports again.  If they appear to be fixed with the new release, then
>> I'd say it's OK to close them.  I'm not sure what to do about those
>> that can't be duplicated or for which we can't get responses to
>> questions we ask to clarify our understanding of the problem (usually
>> that means we are having trouble with duplicating the problem).  If we
>> just close them, then we may be ignoring real problems, but that
>> happen on systems we don't have, or that happen for specific sets of
>> dependencies, compiler and library versions, etc., that are not clear
>> from the report.
> 
> FWIW, my normal dealing in Debian is about the following:
> 1) Try to answer bug reports somewhat fast. So that the reporter knows
> the report isn't ignored. 
> 
> 2) If I can reproduce the bug, tag it as 'confirmed'. If not, tag it as
> 'unreproducible' and 'moreinfo'. Ask the submitter to give more
> information. 
> 
> 3) Bugs that are tagged as 'moreinfo' and don't get more information in
> a reasonable amount of time (like 4 weeks) are closed. 
> 
> Point 3) is pretty strict, but about everyone in FOSS has more things on
> the table than they have time. So hunting after bug reporters to get
> more information is not economic. 
> 
> If I think that a bug is fixed in a newer version, I ask the bug
> submitter to test that version. Ultimately, the idea is to push as much
> work as possible to users -- they outnumber developers by a huge factor,
> so it just makes sense to involve them as much as possible.

This is very sensible, and just what I had been doing on the Octave bug
tracker when I had the time.  I just checked the savannah bug search form
and it is easy to find bugs which have NOT been modified since a given
date.  This makes criteria 3 easy to implement.

Also, my original proposal may have been slightly misinterpreted.  I was
really trying to immediately get rid of a large class of bugs which were
for snapshots or release candidate versions.  For example, "bug #32035:
qr.cc test error on octave-dev source (3.3.54) on MInGW".  It's a single
failing test on an unsupported snapshot which the bug reporter has
acknowledged has been fixed.

--Rik