bug #149713

[Toshio Kuratomi]

On Mon, Feb 28, 2005 at 05:40:10PM +0200, Panu Matilainen wrote:
> On Mon, 28 Feb 2005, Michael Schwendt wrote:
> > The reporter is trying to rebuild all of Extras, looking for compiler
> > warnings. While compilers can be wrong (example: uninitialized variables
> > passed by reference; another example: code which is compiled but never
> > executed at run-time; another example: a missing catch-all rule in a
> > function which is never called with arguments outside its well-defined
> > domain), "array subscript out of range" can lead to memory corruption
> > (write-access beyond array boundary) or undefined behaviour (read-access
> > outside array range).
> >
> > After verifying the compiler's warnings, such reports should be forwarded
> > to upstream developers and are worth fixing, if the code is executed.
> 
> I don't think we can expect an extras packager to fix upstream bugs in the 
> code, packagers deal with *packaging* bugs. If the packager *can* fix bugs 
> (and certainly many can, to some extent at least) then fine, but me thinks 
> things like this can safely be closed with "please report upstream 
> instead" unless the bug is caused by FE-specific changes to the software.
> 
Personally, if I can't fix a bug myself, I still try to take the bug report
upstream.  After all, if I'm going to be packaging this software for the
long term, then I'm going to be interested in watching the upstream bug
report to know when it's resolved.  If I don't understand a reported bug or
can't reproduce it, that's where I hand responsibility to the reporter to take
the issue upstream (I can't report a bug I can't create)

So as a general rule I think packagers are better people to report bugs
upstream rather than the original reporters.  And they can also fix the
problem and provide a patch upstream if they're able to.  I don't know that
I'd say any of this should be required of a packager, though, more of a
"It's good form to do it like this."

-Toshio