Re: 3.4 and bug reports

[Thomas Weber]

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.

        Thomas