Re: [ATTEND] oops.kernel.org prospect

[Dave Jones <davej@redhat.com>]

On Tue, Aug 20, 2013 at 10:22:16AM +0200, Borislav Petkov wrote:
 > On Tue, Aug 20, 2013 at 10:02:43AM +0200, Anton Arapov wrote:
 > > > * Visiting it with chromium gets an annoying warning about the https server
 > > > ...
 > > [snip]
 > > > ...
 > > > 	Dave
 > > 
 > > Thanks, Dave! Will be fixed and improved.
 > 
 > Yeah, collecting oopses is a good idea, so +1.
 > 
 > However, we probably want to think about what exactly we're going to
 > do with that information. For example, if I want to address an issue,
 > I probably want to know how I can reproduce the oops - maybe something
 > like allowing the reporter to add free text note to the oops.

abrt used to have a free-form entry like this.
What happened is users have no idea what to type in there, so you end up
with bugs containing things like "don't know" or worse, some crazy moon
language you can't even read.

 > And yes, as tytso already said, we are very often going to need more
 > info about a system causing the oops (dmesg, lspci, dmidecode, etc,
 > etc). I'm not sure how we're going to collect that without sacrificing
 > some privacy. Or maybe, we could be able to ask people to open a bug on
 > bugzilla.kernel.org where further debugging can take place...

Two things worth noting here, are 1) the original kerneloops also didn't
collect anything like this, and was still very useful, and 2) for the more
common issues (which let's face it, are going to be the only things
people really look at) chances are pretty high that there's going to be
someone also reporting it on lkml, or in a distro bug tracker.

What might be useful however, is collecting things like dmi/lspci/lsusb etc
and _asking_ the user if they're ok with including them at time of filing.
We might scare off some of the more paranoid OMGMYSECRETDATAS users, but
chances are high most people won't care.  This requires the client to have
a UI though, which aiui, it currently doesn't. Anton?

We might also ask if they want to provide an email address for feedback,
but that leads to a bunch of questions about how we expose that to developers
without exposing it to spambots.

	Dave