Re: Number of bugs - statistics

[Natalie Protasevich]

On Thu, May 22, 2008 at 7:51 AM, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
> On Thu, 22 May 2008 17:41:14 +0300
> Adrian Bunk <bunk@xxxxxxxxxx> wrote:
>
>> On Thu, May 22, 2008 at 02:28:17PM +0200, Bosko Radivojevic wrote:
>>
>> > Hi!
>>
>> Hi Bosko!
>>
>> > Is there any kind of analysis of number of (reported or resolved)
>> > bugs through time in Linux kernel floating around? I'm trying to
>> > convince my colleagues that newer kernel version does not mean more
>> > bugs than the previous 'well tested' ones.
>>
>> We definitely have many regressions (something that previously worked
>> does no longer work) in each kernel.
>
> ... and many of those regressions are things people are unlikely to
> hit. And we fix many long standing bugs as well.
>
> Maybe some other data:
> * The incoming rate of ACPI bugs has been pretty much flat the last 3
> years, while the number of Linux (and ACPI) users has grown
> significantly. The number of unfixed bugs has more than halved, from
> over 200 to well below 100.
> * The SCSI maintainer also reports that he sees flat to declining bug
> rates; again with the increase in Linux user base that is a good sign
>
>
>>
>> > Any kind of (research) reports or papers that address this issue is
>> > more than welcome.
>>
>> Any such reports or papers would anyway be flawed since we have no
>> data one could use for doing serious statistics.
>
> We have data for 2.6.25 at least, on which we can and do serious
> statistics. Unfortunately we don't have that for older kernels.
> What we have for older kernels only comes from lkml reports (which
> isn't very representative), but that shows that the bug report pattern
> is a bit spikey, in that kernels that get picked up by popular
> distributions get more reports than those that don't (no big surprise,
> those just have a much larger user base), but otherwise there's no up
> or down trend to be seen there.
>

Majority of old bugs that are still open are of "hard to reproduce"
category. That means you are not very likely to hit them. Those can
be: legacy devices failing, relatively rare hardware, code clean-ups
etc. You can't find  really critical long standing bugs in the old
backlog. It doesn't mean old bugs don't get fixed, rather get less
priority that severe bugs and regressions.
 With emphasys that was put on cleaning up bugs by Andrew and other
developers, bugs are taken even more seriously than before. New bugs,
regressions are being tracked aggressively, so they don't stay open
for long time. You can search for Rafael's regression reports and
sample  time line of a reported regression: they are short lived bugs.
Overall, each kernel release has great deal of improvement over older
ones, by nature of Linux. Many distros now tend to stay as close with
new releases of main line as possible. This seems to be the best way
to get all the bug fixes, optimizations, and features.
Regards,
 --Natalie
>
>>
>> > Thanks!
>> >
>> > Sincerely,
>> > Bosko
>>
>> cu
>> Adrian
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/