mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Natalie Protasevich" <protasnb@gmail.com>
To: "Adrian Bunk" <bunk@kernel.org>
Cc: "Arjan van de Ven" <arjan@infradead.org>,
	"Bosko Radivojevic" <bosko.radivojevic@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Number of bugs - statistics
Date: Thu, 22 May 2008 10:08:49 -0700	[thread overview]
Message-ID: <32209efe0805221008m1850730cxdb26d9bdeb9c43fc@mail.gmail.com> (raw)
In-Reply-To: <20080522165008.GB2727@cs181133002.pp.htv.fi>

On Thu, May 22, 2008 at 9:50 AM, Adrian Bunk <bunk@kernel.org> wrote:
> On Thu, May 22, 2008 at 09:20:46AM -0700, Natalie Protasevich wrote:
>> On Thu, May 22, 2008 at 8:54 AM, Adrian Bunk <bunk@kernel.org> wrote:
>> > On Thu, May 22, 2008 at 07:51:35AM -0700, Arjan van de Ven wrote:
>> >> On Thu, 22 May 2008 17:41:14 +0300
>> >> Adrian Bunk <bunk@kernel.org> 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
>> >
>> > Andrew sees and handles the majority of incoming bug reports.
>> > Ask him whether he agress with this.
>> >
>> > And ALSA alone has 2000 open bug reports, which makes the open ACPI or
>> > SCSI bug numbers relatively irrelevant in any "number of bugs"
>> > statistics.
>> >
>> >> > > 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.
>> >>...
>> >
>> > Where do we have data for 2.6.25 covering all kinds of bugs?
>> >
>> > Regressions reported before 2.6.25 and Oops'es etc. are only a small
>> > part of the picture.
>>
>> There is no unified tracking mechanism as of now, this is a big
>> problem. There are some projects that have ideas about universal bug
>> tracking, for example some people from KDE team expressed their ideas,
>> I'm planning to get back with them.
>> It would be great if all reports from known and unknown bugzillas were
>> piped into one place and sorted out,
>
> Not everyone uses Bugzilla (e.g. ALSA uses Mantis).
>
> And the majority of bug reports might still go only to mailing lists and
> not into any bugtracker at all. As long as this happens the data is
> simply not available.

True. It was argued that mailing list is more effective that bugzilla
as a collaboration mechanism while working on a bug. But  if it was a
way to record it into bugzilla "seemlessly" (as Andrew tried to
enforce, by asking those on the list to add CC to bugme-deamon) this
would be perfect.
Another one to implement...
>

>> by various criteria: ALSA bugs
>> are numerous, which is not important for most enterprise server users
>> who would completely disregard this category, whereas desktop users
>> will probably concentrate on those more than any other.
>
> The majority of machines running Linux most likely runs with ARM CPUs.
>
> Show me any public source you want to use for getting serious data for
> this area.

There is no one, except dispersed reports and ... appropriate
implementation involving search engine comes to mind.
>
>> So the answer
>> to question about kernel stability would be more adequate depending on
>> who's asking.
>
> You must not confuse "number of reported bugs" with "kernel stability" -
> these two can be quite decoupled.

Number of existing, proven and prioritized  bugs maybe better to say.
I think there is a correlation.
--Natalie
>
>> --Natalie
>
> cu
> Adrian
>
> --
>
>       "Is there not promise of rain?" Ling Tan asked suddenly out
>        of the darkness. There had been need of rain for many days.
>       "Only a promise," Lao Er said.
>                                       Pearl S. Buck - Dragon Seed
>
>

  reply	other threads:[~2008-05-22 17:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-22 12:28 Bosko Radivojevic
2008-05-22 14:41 ` Adrian Bunk
2008-05-22 14:51   ` Arjan van de Ven
2008-05-22 15:47     ` Natalie Protasevich
2008-05-22 15:54     ` Adrian Bunk
2008-05-22 16:20       ` Natalie Protasevich
2008-05-22 16:50         ` Adrian Bunk
2008-05-22 17:08           ` Natalie Protasevich [this message]
2008-05-22 17:33             ` Adrian Bunk
2008-05-22 17:51               ` Natalie Protasevich
2008-05-22 18:11                 ` Adrian Bunk
2008-05-22 22:18           ` Arjan van de Ven
2008-05-23  9:09             ` Adrian Bunk
2008-05-23 14:11               ` Arjan van de Ven
2008-05-23 16:50                 ` Adrian Bunk
2008-05-23 18:29                   ` Arjan van de Ven
2008-05-23 20:31                     ` Adrian Bunk
2008-05-26 17:05                       ` Dave Jones
2008-05-23 10:35           ` James Courtier-Dutton
2008-05-23 15:35             ` Takashi Iwai
2008-05-22 16:22       ` Stefan Richter
2008-05-22 16:38         ` Bart Van Assche
2008-05-22 17:09         ` Adrian Bunk
2008-05-22 17:45           ` Stefan Richter
2008-05-22 19:17             ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32209efe0805221008m1850730cxdb26d9bdeb9c43fc@mail.gmail.com \
    --to=protasnb@gmail.com \
    --cc=arjan@infradead.org \
    --cc=bosko.radivojevic@gmail.com \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®