public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Daniel Bonekeeper <thehazard@gmail.com>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Automatic Kernel Bug Report
Date: Sun, 9 Jul 2006 21:11:08 +0200	[thread overview]
Message-ID: <20060709191107.GN13938@stusta.de> (raw)
In-Reply-To: <e1e1d5f40607091146s2f8e6431v33923f38c6d10539@mail.gmail.com>

On Sun, Jul 09, 2006 at 02:46:28PM -0400, Daniel Bonekeeper wrote:
> >I'm sorry for being so negative, but it seems you are overdesigning a
> >solution for a non-existing problem:
> >
> >There are cases where the machine is simply dead with exactly zero
> >information. These are the really hard ones.
> 
> Then really there isn't anything that we can do, except to expect the
> kindness of the user in taking a picture of his screen and posting on
> the kernel's bugzilla.

No, I'm talking about freezes without anything printed.

As soon as anything is printed, it becomes easier.

> >Then there are cases where the kernel is able to print a BUG() or Oops
> >to a log file. Or the error message is printed to the screen and the
> >user uses a digital camera and sends the photo.
> 
> Then again, users may just continue using the machine (without even
> noticing the Oops), or notice but never care to report it, or forgets,
> etc.

If the user doesn't notice what is written into his logs, the solution 
is to change this (e.g. via logcheck).

And if the user doesn't care, there's no reason for getting the bug 
report - a bug report from a not responsive user is worse than no bug 
report.

> >The message is usually enough for starting to debug the problem or
> >asking the user for additional information.
> >
> >But most important, the problem lies in a completely different area:
> >
> >Interaction between kernel devlopers and users is not a real problem.
> >The real problem is the missing developer manpower for handling bug
> >reports.
> 
> Well Adrian, this is the other side of the problem. We don't actually
> need a kernel monkey to keep looking for bugs that comes (even thought
> would be good, but as you stated, there is not enough manpower to do
> that), even more after having something that automatically sends Oops
> reports to the server, where we could expect thousands of bug reports
> daily... but I also believe that not having somebody to look at them
> is not an excuse for not having this bug taken account for. For
>...
> In resume, don't being able to investigate each report isn't a reason
> for not being acknowledged of its existance, and even we don't
> investigate it, having it for statistical purposes is already a great
> deal.

I'm still sure the important points are
- developer manpower and
- responsive bug submitters,
and your proposal doesn't help with any of these.

But this is open source, so feel free to send a patch implementing your 
ideas and prove me wrong.

> Daniel

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:[~2006-07-09 19:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-09  8:45 Automatic Kernel Bug Report Daniel Bonekeeper
2006-07-09  9:45 ` Michal Piotrowski
2006-07-09 10:29   ` Daniel Bonekeeper
2006-07-09 12:58     ` Adrian Bunk
2006-07-09 18:46       ` Daniel Bonekeeper
2006-07-09 19:11         ` Adrian Bunk [this message]
2006-07-09 20:01           ` Daniel Bonekeeper
2006-07-09 20:19             ` Valdis.Kletnieks
2006-07-09 20:27               ` Daniel Bonekeeper
2006-07-10  8:11                 ` Pavel Machek
2006-07-10 17:40                   ` Daniel Bonekeeper
2006-07-10 17:59                     ` Valdis.Kletnieks
2006-07-10 22:05                       ` Daniel Bonekeeper
2006-07-10 23:41                         ` Lee Revell
2006-07-11  1:15                           ` Daniel Bonekeeper
2006-07-10 18:41                     ` Horst von Brand
2006-07-10 21:34                       ` Daniel Bonekeeper
2006-07-11 14:16                         ` Horst von Brand
2006-07-09 20:24             ` Diego Calleja
2006-07-09 20:37               ` Daniel Bonekeeper
2006-07-09 22:19                 ` Diego Calleja
2006-07-09 22:49                   ` Daniel Bonekeeper
2006-07-09 20:25             ` Jesper Juhl

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=20060709191107.GN13938@stusta.de \
    --to=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.k.k.piotrowski@gmail.com \
    --cc=thehazard@gmail.com \
    /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