{"id":111,"date":"2007-07-06T16:30:22","date_gmt":"2007-07-06T23:30:22","guid":{"rendered":"http:\/\/ryanorser.com\/?p=111"},"modified":"2007-07-06T16:30:22","modified_gmt":"2007-07-06T23:30:22","slug":"20070706-ubuntu-development-announcement","status":"publish","type":"post","link":"https:\/\/ryanorser.com\/index.php\/2007\/07\/06\/20070706-ubuntu-development-announcement\/","title":{"rendered":"2007\/07\/06 Ubuntu-Development-announcement:"},"content":{"rendered":"

The Topic for today is:<\/p>\n

1. Changed behaviour of Apport crash bugs (Martin Pitt)<\/p>\n

Hello fellow Ubuntu developers,<\/p>\n

Until now, crash bugs filed by Apport [1] had two major problems:<\/p>\n

* They potentially contain sensitive information in the core dump and
\nstack traces.<\/p>\n

* They produce a lot of bug email noise; a lot of it is redundant,
\nand with the new automatic duplicate detection a lot of those bugs
\ndo not need to be looked at at all any more.<\/p>\n

Eventually, Launchpad will grow a proper concept of a crash database
\nto fix that. Until we get that, we need a quick fix for that, which is
\nwhy I implemented [2] now:<\/p>\n

* Crash bugs are filed private now, with only ubuntu-core-dev (for
\nmain\/restricted) and ubuntu-dev (for universe\/multiverse) members
\nbeing able to see them initially. After verifying that there is no
\nsensitive data, the bugs can be marked as public if there is a
\nreason to do so (like pointing upstreams to it).<\/p>\n

* There will be no bug email sent at all until someone marks a bug
\nas public.<\/p>\n

I added some detailed explanations to the HowToTriage wiki page [3],
\nwhich also describes the steps bug triagers should do with Apport
\ngenerated crash bugs.<\/p>\n

Thank you,<\/p>\n

Martin<\/p>\n

[1] https:\/\/wiki.ubuntu.com\/Apport<\/a>
\n[2] https:\/\/wiki.ubuntu.com<\/wbr>\/CrashReporting<\/a>
\n[3] https:\/\/wiki.ubuntu.com\/Bugs<\/wbr>\/HowToTriage#head-f46ac7bd66be<\/wbr>716a03d2d4fb0788725cc9cc7ba0<\/a><\/p>\n