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
| ||
|
Date: Mon, 14 Apr 2008 00:21:18 +0400 From: Evgeniy Polyakov <johnpol@....mipt.ru> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Willy Tarreau <w@....eu>, "Rafael J. Wysocki" <rjw@...k.pl>, Tilman Schmidt <tilman@...p.cc>, Valdis.Kletnieks@...edu, Mark Lord <lkml@....ca>, David Miller <davem@...emloft.net>, jesper.juhl@...il.com, yoshfuji@...ux-ipv6.org, jeff@...zik.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: Reporting bugs and bisection (was: Re: 2.6.25-rc8: FTP transfer errors) Hi. On Sun, Apr 13, 2008 at 12:18:31PM -0700, Andrew Morton (akpm@...ux-foundation.org) wrote: > > One other thing which might get confusing/frustrating on the > > user side is that currently, Linux is the *only* product which requires > > the bug reporter to find the fault change > > That's because many (probably most) Linux bugs are dependent upon the > hardware which they run on, and developers cannot reproduce the failure on > their hardware. Other software products don't have that problem. Bugs are bugs, they either depend on hardware or do not. There is no perfect world where after reporting subtle bug it will be fixed. It is not Linux, it is everywhere. Bugs are only fixed when they have major impact. Only. Either by having exploit, or crash, or good testcase. Or bisect result. This just a tool to help both parties. And a huge help for regressions. If bug would exist for years, bisection unlikely to help. > That being said.. four or five years ago, developers would often work > closely with the reporter working out why the reporter's failure was > occurring. Several days of back-and-forth. Yeah, spent two weeks kicking all possible stuff around and eventually drop that namespace patch at all to find where the problem was. We started to move further. Bisect is just a tool. It is not something developers throw into user when they do not want to work. This _is_ a help, which allows both to solve problem in the fastest way. If the same would be done on developers machine and huge patches would be sent to jump between changesets, that would be a real 'work closely with the reporter working out why the reporter's failure was occurring'? You pointed it yourself: several days of back-and-forth. With this helping automation tool called bisect bug was resolved in 15 minutes after completion. Completion itself took couple of hours. > We dont' do that as much nowadays - there's a tendency to > > a) throw the problem back at the reporter, often asking them to bisect. > If the reporter is running a distro kernel (eg: Fedora) then that's > quite hard, and often isn't a think they have knowledge to do. So > they'll just disappear. Or > > b) just ignore the report altogether. There is also global warming tendency. IIRC. Bugs _are_ fixed, Andrew. And developers did not change suddenly to selfish bastards who do not care for users. They just developed a tool, which greatly helps to both and saves lots of users time, since regression gets fixed with this tool really quickly. Bisect is not asked to be performed without a reason. For subtle bug it is the fastest way, but otherwise there might be a long conversation. And even in this really subtle case there was a dialog. Bisect automation does not add kind relations though, but we can ask Linus to add couple of smiles into the output. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists