qutebrowser crash reports

Florian Bruhin me at the-compiler.org
Wed Jan 21 06:46:02 CET 2015


Hi,

(Cc-ing this to the list because I'd like some discussion and ideas
about this. For people who have already spoken out about the confusing
crash dialog issue - I hear you, I just want to hear more opinions
an am unsure about what's best)

* Doug Stone-Weaver <doug at stone-weaver.com> [2015-01-16 01:58:36 -0800]:
> Good question - do you generally follow up with ALL crash reports?

I'd like to, but maybe one out of twenty has contact information.

Let's say the distribution of crash reports looks roughly like this,
at least right now with v0.1.2 which is quite stable.

- 5% real qutebrowser problems which need to be fixed. Those are
  usually easy, the exception and debug log gives me all information I
  need. I'd still like to follow-up with people and at least tell them
  the github issue link, so they can subscribe. But this is like 1
  report by week, and I don't expect it to increase much, unless I
  fsck up something.

- 50% segfaults because of distributions like Debian/Ubuntu which are
  still on an older Qt version. I'd like to tell people it's not
  actually a qutebrowser problem, and they should please wait for
  their distribution to upgrade.

- 10% segfaults which could somehow be worked around in qutebrowser,
  but I don't have any info, so I can't. The debug log on segfaults
  usually only says "qt_mainloop", so I don't know *anything*, but I'd
  desperatly like to fix the problem.

- 35% issues in qutebrowser which are already fixed, but people didn't
  upgrade for months. I'd like to tell them to do.

> I was expecting my second crash to just get lumped in with the first (if
> I'm remembering correctly and the stacks where the same), so I didn't
> think you'd need more info, hence I didn't expect the email.
> 
> If you're planning to follow up with everyone who hits a crash and
> submits a report (at least for now :))... here are some super subjective
> thoughts on what might have made me expect an email.

Thanks! I added them to
https://github.com/The-Compiler/qutebrowser/issues/447

> 2) It might be worth flipping the order of the
> boxes, so people enter their contact information first. It's possible
> that this will lower the hit rate of people entering repro steps... but
> I imagine it would increase the hit rate of people who give you their
> contact information? Maybe some A/B testing :) - just kidding.

People usually submit neither, or both. Most of the time neither.
Right now, the "OK" button being a report if you don't pay attention
kinda tricks them into reporting bugs even if they don't want to - but
in case of exceptions those are useful as well.

See the first point in the issue above - it'd stop people from
accidentally reporting info they don't want to, but I'm afraid I'll
also lose many useful reports if users really make a choice between
reporting and not. What do you think?

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20150121/f846c7ac/attachment.sig>


More information about the qutebrowser mailing list