apport symptom based reporting

Bryce Harrington bryce at
Mon Feb 22 18:31:29 UTC 2010

On Mon, Feb 22, 2010 at 12:57:24PM +0000, Andy Whitcroft wrote:
> On Mon, Feb 22, 2010 at 12:51:06PM +0000, Andy Whitcroft wrote:
> > I have just had a strange experience with the symptom based reporting
> > in apport.  I have obviously had some kind of kernel issue, either a
> > delayed failed suspend/resume report or perhaps an oops which has not
> > had any physical effect I am aware of.  I get the apport report of a
> > 'serious kernel issue' and asked to report it; note that I was previously
> > unaware of the problem.  Now the first question is 'Has this issue been
> > confirmed to exist with the upstream kernel?" and I have yes/no as options.
> Indeed the next question is then 'Do I want to test it upstream?', and
> after that 'Is this a regression?', then 'is it reproducible'?

Hmm, these might not be good questions to put in the apport symptom

1.  "Has this issue been confirmed to exist with the upstream kernel?"

The hook can just look at what kernel has been booted; if it's an
upstream kernel, it can assume yes.  If it's not, then it can tell the
user to boot an upstream kernel (and give a pointer to how they can do
this (maybe even offer to install it)) if this is required for filing
the bug.

2.  'Do I want to test it upstream?'

The user really doesn't need to be asked their opinion on this.  If it
is required to test it, just tell them they have to test against the
upstream kernel (and help them do it), otherwise let the bug be filed
and then recommend they do this (if needed) later during triaging.

3.  'Is this a regression?'

This actually probably is a good question, but I don't know that users
will necessarily answer it correctly.  Maybe it would be better to ask
in the inverse, as in, "Is this new hardware?" > "Has it ever worked

4.  'Is it reproducible?'

Also probably a good question (it seems like apport ought to be able to
determine this itself, by keeping track of previously encountered


More information about the kernel-team mailing list