问题描述
曾经是程序崩溃时，特别是当用户使用Ubuntu的pre-release时，可以使用apport打开错误报告。然后，用户可以跟踪错误，看看它是否会影响其他人，帮助修复错误等。
从Precise 12.04开始，此行为和工作流程发生了变化。正如我在Bug #993450 “Apport fails to submit bug report”中发现的那样，默认情况下，apport不再打开错误报告(这样做很尴尬但并非不可能)。与此同时，人们注意到一个新的”whoopsie”流程，如What is the ‘whoopsie’ process and what does it do?所述。
经过一些谷歌搜索后，我挖出了这个蓝图，描述了整个过程：ErrorTracker – Ubuntu Wiki。 (它没有提到whoopsie或daisy，所以我添加了它们 – 如果我弄错了，请纠正我)。
哇 – 这听起来很精彩，可以简化和改进崩溃报告流程。
我留下了这个问题：用户如何了解问题的状态？蓝图现在有这个要求
The user should have some way to check back on the status of their crash report; e.g. have some report ID they can look at to see statistics and/or any associated bug #. E.g. provide a serial number at time of filing that they can load via a web page later on.
这似乎没有实现。在此期间有什么可用的吗？
开发者如何进入游戏？转到https://daisy.ubuntu.com只是提供“不正确的Content-Type”错误消息。
最后，我建议在发行说明中记录apport行为更改。任何试图帮助Ubuntu的人都应该感兴趣。
最佳解决方法
感谢您对Ubuntu error tracker project的关注。
As of Precise 12.04, this behavior and workflow changed. As I discovered in Bug #993450 “Apport fails to submit bug report”, by default apport no longer opens a bug report (and it is awkward but not impossible to get it to do so).
Apport从未创建错误报告post-release。当版本仍处于开发阶段时，您可以使用apport来提交Launchpad错误(以及错误报告)。
在最终发布的Ubuntu版本中，我们现在显示错误对话框。这是一个很好的改进，从程序”going away”没有任何反馈，用户不知道刚刚发生了什么。
当人们选择发送这些报告时收集的数据的统计数据显示在http://errors.ubuntu.com上。
I’m left with this question: how does a user learn what the status of the problem is? The blueprint now has this requirement
The user should have some way to check back on the status of their crash report; e.g. have some report ID they can look at to see statistics and/or any associated bug #. E.g. provide a serial number at time of filing that they can load via a web page later on.
我要删除它。这绝不是意图。用户界面小心不要做出有关获取报告反馈的承诺。
这些不是错误报告。
我们的目的是减少开发人员找到最紧迫问题所需的时间，收集修复它们所需的信息，并为用户提供修复。
我们已经解决了找到最紧迫问题的问题。这是http://errors.ubuntu.com的首页。
在foundations-q-bucketing-improvements中解决了快速收集所需信息，并且没有涉及遇到问题的用户的长反馈循环的问题。该计划是允许开发人员挂钩信息收集过程server-side。如果我需要/var /log /syslog但它尚未提供，我只需更改http://errors.ubuntu.com上的设置，下一个遇到错误的人会自动将其添加到他们发送的数据中。
foundations-q-updates-from-crash-reports解决了快速获取用户问题的方法。当用户提交错误报告并且该错误已经修复并发布时，会出现一个对话框，询问他们是否要升级到修复他们刚刚遇到的问题的软件版本。
And how does a developer get into the game? Going to https://daisy.ubuntu.com just provides an “Incorrect Content-Type” error message.
http://daisy.ubuntu.com不适合人类使用。它是用于向其发送报告的错误报告守护程序(whoopsie)。
对其他人来说，参与是绝对精彩的。我目前是唯一一个攻击这个full-time的人。
该系统有四个部分。
-
Apport，提供桌面用户界面。
-
Whoopsie，它接收由Apport创建的报告(和核心转储)并将它们拖入错误跟踪服务器Daisy。
-
Daisy，收集Whoopsie的报告并处理它们。这是服务的核心。这就是将核心文件转换为回溯报告并生成您在http://errors.ubuntu.com上看到的统计数据的原因。
-
Errors，这是一个Django-based网站，提供人类可读的数据视图和RESTful API，可以使用它。
在lp:daisy的setup /目录下有一个轻微的out-of-date脚本集，可以让您了解这些部分如何组合在一起。我一直在研究juju魅力来取代它。目标是在云中部署整个基础架构以进行测试和开发的单一命令。
如果您有进一步的开发问题，可以在Launchpad上找到我的电子邮件地址。
更多信息：