Message-ID: <20080413202118.GA29658@2ka.mipt.ru>
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 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/

Powered by blists - more mailing lists