apport symptom based reporting

[Leann Ogasawara]

On Mon, 2010-02-22 at 10:31 -0800, Bryce Harrington wrote:
> 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
> hook:
> 
> 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.

We don't require that it be confirmed/tested with the upstream kernel
but it's definitely a nice to know bit of information.  But you're right
that we should be able to automatically determine if they're already
running and reporting with an upstream kernel.

> 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.

Ack.  At the moment it seems we should refactor this to be more of an
informational blurb rather than a question.

> 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
> before?"

Maybe we (meaning I or JFo) can sample the currently tagged regressions
which were filed via apport and determine if they've been tagged
properly before we look if we really need to re-work this.

> 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
> crashes.)

Definitely sounds like something reasonable for bugs (for ex kernel
oops) which apport can detect.  I'll see if I can find out how this
could work.

Thanks,
Leann