From: Ingo Molnar <mingo@elte.hu>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg KH <greg@kroah.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Top 10 bugs/warnings for the week of March 23rd, 2008
Date: Mon, 26 May 2008 11:36:09 +0200 [thread overview]
Message-ID: <20080526093609.GF13529@elte.hu> (raw)
In-Reply-To: <4837A2A3.2030204@linux.intel.com>
* Arjan van de Ven <arjan@linux.intel.com> wrote:
>> At any rate, they have a bug in their proprietary module (news at
>> 11).
>>
>> So, I don't think this should make the top ten. Do you have a way to
>> sort tainted vs non-tainted, and only produce the top ten for
>> untainted?
>
> yes absolutely; this is a question I'll have for the customers of the
> data... do people want to see "only-tainted" in these top 10s? Right
> now I mark them as such but leave them in. It's trivial for me to just
> leave them out instead (the info is there, just a matter of not
> counting)
i think they should be included, but perhaps abbreviated [into 1-2
lines] so that they do not hold us up.
We must not whitewash our bug statistics by intentionally excluding the
harm that bin-only modules do to our users - but we can make them less
visually intrusive, so that we can work on fixing the bugs we can fix.
Perhaps make sure it's top 10 of _our_ bugs, with the bin-only data
mixed in as well (in a visually unintrusive way) to make the picture
complete. I.e. list 20 bugs if 10 of them are bin-only modules.
Ingo
next prev parent reply other threads:[~2008-05-26 9:36 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-23 16:19 Top 10 bugs/warnings for the week of March 23rd, 2008 Arjan van de Ven
2008-05-23 16:23 ` Top 10 bugs/warnings for the week of May " Arjan van de Ven
2008-05-23 16:42 ` Top 10 bugs/warnings for the week of March " Linus Torvalds
2008-05-23 17:35 ` Arjan van de Ven
2008-05-23 19:31 ` Alan Cox
2008-05-24 0:15 ` Chris Wright
2008-05-24 5:07 ` Arjan van de Ven
2008-05-26 9:36 ` Ingo Molnar [this message]
2008-05-24 5:32 ` Greg KH
2008-05-24 22:23 ` Jan Kara
2008-05-24 22:30 ` Arjan van de Ven
2008-05-24 22:45 ` Theodore Tso
2008-05-25 11:58 ` Stefan Richter
2008-05-26 9:39 ` Ingo Molnar
2008-05-26 10:16 ` Theodore Tso
2008-05-26 10:48 ` Ingo Molnar
2008-05-26 16:20 ` Jan Kara
2008-05-26 16:48 ` Ingo Molnar
2008-05-26 17:01 ` Theodore Tso
2008-05-26 17:09 ` Oliver Neukum
2008-05-26 17:28 ` Bart Van Assche
2008-05-26 17:38 ` Jan Kara
2008-05-26 17:50 ` Theodore Tso
2008-05-26 18:23 ` Ingo Molnar
2008-05-27 6:12 ` Oliver Neukum
2008-05-27 11:41 ` Pavel Machek
2008-05-27 3:49 ` Greg KH
2008-05-27 11:40 ` Pavel Machek
2008-05-26 14:52 ` Stefan Richter
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=20080526093609.GF13529@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=chrisw@sous-sol.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.