linux-kernel - Re: 2.6.25-rc8: FTP transfer errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Apr 2008 00:09:11 +0200
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"Tilman Schmidt" <tilman@...p.cc>
Cc:	"David Miller" <davem@...emloft.net>, lkml@....ca,
	yoshfuji@...ux-ipv6.org, jeff@...zik.org, rjw@...k.pl,
	linux-kernel@...r.kernel.org, linux-net@...r.kernel.org
Subject: Re: 2.6.25-rc8: FTP transfer errors

On 10/04/2008, Tilman Schmidt <tilman@...p.cc> wrote:
<...>
>
>  Bisecting is a time-consuming process. If unwillingness to bisect
>  is unacceptable in a bug reporter then people who don't have the
>  time to bisect must stop reporting the problems they encounter.
>

I hope that was a joke and that I just don't get it.

Are you really saying that if somebody find a bug they shouldn't
bother reporting it unless they are willing to spend hours and hours
of work to get it fixed?

The way I see it, the burden of debugging and fixing bugs is mainly on
the developers of the code that breaks. You can't blame users for
using the code, triggering bugs and then reporting the breakage.
Users who report bugs are doing us all a great service regardless of
their ability or willingness to do more work than just the initial
report.

If bugs don't get reported they'll never get fixed. Even a bad bug
report with no follow up at all still allows us to use it to gauge how
often a specific bug is being hit and thus how important it may be to
fix it.

You can't expect users to know how to debug a problem or even bisect
it. A user may not even be able to compile a custom kernel but she may
still hit a bug and do us the favour of reporting it. It should be the
job of the developer of the code to investigate the bug following a
users report.

Sure it's great when users can bisect, provide test cases, debug the
problem completely themselves or even provide a patch, but you can't
expect that. And in my oppinion you certainly can't just hide behind
"the user doesn't want to bisect so I won't fix this" and use that as
an excuse for the code being buggy. I hope most people take bug
reports more seriously than that.

When people discover bugs in my own code I thank them and feel a bit
ashamed that I didn't do my work properly and it then becomes very
important to me to make sure I squash the bug.  The more the user can
help the better, but if they cannot help beyond telling me what broke
and how, then that's fine too. I still want to nail the bug and I'll
just have to do more work myself, but it becomes a matter of personal
and professional pride to hunt down the bug.

We need to be grateful to users who report bugs - most of them don't bother.

-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/