ReportBugs2

Differences between revisions 5 and 6
Revision 5 as of 2008-04-28 16:35:54
Size: 324
Editor: lrc7-alba
Comment:
Revision 6 as of 2008-05-03 19:04:55
Size: 13276
Editor: 194
Comment: Logs upload
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:


=== jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Reporting Bugs" - Brian Murray

[17:58] <jcastro> ok, next up is Reporting Bugs with Brian Murray

[17:59] <jcastro> this session was done on Monday but we scheduled one today to get maximum
participation!

[17:59] <bdmurray> Hi, I'm Brian Murray and I'm Ubuntu's bug master.

[18:00] <bdmurray> I'm here to talk today about how to report bugs about Ubuntu as there are
various ways you can do it.

[18:00] <bdmurray> Additionally, I'll cover how to make your bug report more complete and
therefore more likely to get fixed!

[18:00] <bdmurray> Perhaps you are wondering what exactly is a bug?

[18:01] <bdmurray> In computer software it is an error or a flaw that makes it behave in ways
for which it wasn't designed.

[18:01] <bdmurray> Some of these can result in crashes, others may have a subtle effect on
functionality, others can be spelling errors.

[18:01] <bdmurray> By reporting these issues you can help to make Ubuntu even better than it
already is.

[18:02] <bdmurray> Reported bugs are kept in Launchpad, the bug tracking system used by
Ubuntu.

[18:02] <bdmurray> Let's look at a sample bug report - http://launchpad.net/bugs/222278.

[18:03] <bdmurray> There are 4 things there that I want to point out.

[18:03] <bdmurray> 1) The bug's title or summary is 'upgrade hanges in checkViewDepends()'

[18:04] <bdmurray> 2) In the affects table, below the title, you'll see that this bug report
affects 'update-manager (Ubuntu)'

[18:04] <bdmurray> This is the package / application which the bug is about

[18:04] <bdmurray> 3) Below that is the bug's description, labelled "Bug description" ;),
which is filled out when you are reporting a bug

[18:05] <bdmurray> 4) You'll also notice that there are 5 comments, 4 of which contain
attachments with supporting information about the bug.

[18:05] <bdmurray> So, that's what a bug report looks like. Are there any questions about
the format of a bug report or what a bug is?

[18:07] <bdmurray> < wolfger> QUESTION: if something is behaving as designed, but we don't
like it, is it bug report material?

[18:08] <bdmurray> Yes, that is a valid bug however it is ultimately up to the developers of
that particular piece of software whether or not they will fix it.

[18:09] <bdmurray> < smeg0l> QUESTION when do determine if it's a hardware faily or a bug ?

[18:10] <bdmurray> Determining whether or not a bug report is due to faulty hardware can be
quite tricky.

[18:11] <bdmurray> Most of those bug reports would be about the kernel and by looking at
kernel log files we can help you determine whether or not it is a hardware or software issue.

[18:11] <bdmurray> Moving on - How can bugs be reported to Launchpad?

[18:12] <bdmurray> They can be reported via the web interface at
https://bugs.launchpad.net/ubuntu/+filebug where you start by filling out the summary which
becomes the bug's tile.

[18:12] <bdmurray> After which you are asked for the package affected and for 'Futher
information' which becomes the bug's description.

[18:12] <bdmurray> The description should contain at a minimum the following:

[18:13] <bdmurray> 1) The release of Ubuntu that you found the bug in.

[18:13] <bdmurray> This is important as there is more than 1 supported release of Ubuntu out
there right now.

[18:13] <bdmurray> 2) The version of the package you found the bug in.

[18:14] <bdmurray> 3) The behaviou that you expected to happen

[18:14] <bdmurray> and 4) What happened instead

[18:14] <bdmurray> You also have the opportunity to add an attachment to your bug when you
are reporting it via the web interface.

[18:15] <bdmurray> Another way to report a bug is using apport an automated problem report
application included with Ubuntu.

[18:15] <bdmurray> The advantage to using apport is that it automatically collects information about the release of Ubuntu you are using and the version of the package / application that you are reporting the bug about.

[18:15] <bdmurray> Let's say that you have encountered a bug with Firefox.

[18:15] <bdmurray> You can use apport to report the bug by going to Firefox's "Help" menu and
choosing "Report a Problem".

[18:16] <bdmurray> Apport will start collecing information about your bug and then open a new
window where you enter the bug's summary / title and then enter the bug's description.

[18:17] <bdmurray> Let's look at a bug reported using the "Report a Problem" menu item

[18:17] <bdmurray> http://launchpad.net/bugs/223455

[18:17] <bdmurray> At the bottom of the description you'll see information regarding the
DistroRelease, the package and version, and kernel version among other things.

[18:18] <bdmurray> All of this information is gathered for you automatically.

[18:18] <bdmurray> The "Report a Problem" functionality has been integrated into lots of
applications and is the preferred way to report a bug.

[18:19] <bdmurray> Additionally, apport has a command line interface, called apport-cli,
where you can report a bug about a specific package via 'apport-cli -f -p PACKAGE' which is
useful for non GUI applications.

[18:19] <bdmurray> Additionally, you can also specify a process id number via 'apport-cli -f
-P PID'.

[18:19] <bdmurray> Further information about reporting bugs can be found at
https://help.ubuntu.com/community/ReportingBugs

[18:20] <bdmurray> Are there any questions about how you can report a bug?

[18:21] <bdmurray> < lyzium> Question: can apport initialise outside given example. If
firefox crashes on start you are unable to launch the "report a problem" option

[18:21] <bdmurray> In that case you could use apport-cli -f -p firefox-3.0 for example

[18:22] <bdmurray> Also when you are running a development release of Ubuntu apport will
watch for application crashes and report those

[18:23] <bdmurray> < Lardarse> QUESTION: Do you find that the differences between the
developer's definition of a bug (to quote you: "an error or a flaw that makes it behave in
ways for which it wasn't designed") and the end-users definition (to word it in the same
way, it's usually something along the lines of "an error or a flaw that makes it behave in
ways that don't make

[18:23] <bdmurray> sense") cases problems for you and for lthe other people inv

[18:24] <bdmurray> Ubuntu is designed for "human beings" and if an application behaves in a
way that doesn't make sense then their is something wrong.

[18:25] <bdmurray> Possibly there is a bug in the documentation or the software's
description.

[18:26] <bdmurray> That bug report won't have as a high of priority as a crash report or
other bugs but it still is a valid bug.

[18:26] <bdmurray> So how can we make our bug reports more useful for developers?

[18:26] <bdmurray> Choosing the name of the package or application the bug is about is
critical.

[18:27] <bdmurray> If a bug does not have a package assigned to it is much less likely to get
looked at by anyone let alone the developer of that application.

[18:27] <bdmurray> Some helpful hints for finding the proper package are at
https://wiki.ubuntu.com/Bugs/FindRightPackage

[18:27] <bdmurray> This page also contains the names of packages that might be hard to
discover.

[18:27] <bdmurray> For example, bugs about the kernel in Hardy Heron should be reported about
the 'linux' package.

[18:28] <bdmurray> Additionally, members of the Ubuntu bug squad are available in the
#ubuntu-bugs cahnnel if you need help identifying the proper package.

[18:29] <bdmurray> After the bug is reported in Launchpad an important part of its life cycle
is it entering the Confirmed status.

[18:29] <bdmurray> Pedro will talk about this more in the next class, but when a bug is
Confirmed it means that someone has been able to recreate the bug or believes sufficient
information has been included in the bug report for a developer to start working on it.

[18:29] <bdmurray> Any Launchpad user can confirm a bug report, but please don't confirm your
own!

[18:30] <bdmurray> This will make the Confirmed status less useful.

[18:30] <bdmurray> What this means is that you should include extremely detailed steps to
recreate the bug in it's description so anyone, not just a developer, could confirm it.

[18:31] <bdmurray> Let's take OpenOffice for example, there are phenomenal amount of things
you can do in the Word Processor or the Spreadsheet parts of it.

[18:31] <bdmurray> And not every bug triager may now all the intricacies of that application.

[18:32] <bdmurray> So by putting extremely detailed steps in your bug report you are
increasing the chances of it being confirmed.

[18:32] <bdmurray> It is far better to have too much detail than not enough!

[18:33] <bdmurray> Some fairly simple things you can do to make your report easier for
someone to confirm are including a screenshot.

[18:33] <bdmurray> Or you can create a screencast, a movie of your desktop, using an
application like istanbul.

[18:34] <bdmurray> Let's take a look at http://launchpad.net/bugs/212425

[18:34] <bdmurray> This bug has a screencast attached to it

[18:35] <bdmurray> Their description of how to reproduce the bug is pretty good but is a
little hard to understand

[18:36] <bdmurray> By watching the screencast though, bug triagers are able to clearly see
what steps we should take to recreate the bug.

[18:37] <bdmurray> Are there any more questions at this point in time?

[18:38] <bdmurray> < BonesolTeraDyne> QUESTION: Are there any plans to make a KDE version of
Apport, or to at least give the KDE crash handler some sort of LP integration?

[18:40] <bdmurray> There are some crash reports about KDE applications reported by apport.

[18:41] <bdmurray> In regards to integration with the KDE crash handler, I'm not certain but
will look into it.

[18:42] <bdmurray> One of the best ways to make your bug report more likely to be fixed is to
follow the debugging procedures for the package or subsystem your bug is about.

[18:44] <bdmurray> Bug triagers and software developers have written up a variety of these
debugging procedures.

[18:44] <bdmurray> A list of them can be found at https://wiki.ubuntu.com/DebuggingProcedures

[18:46] <bdmurray> If you look at the debugging update-manager page -
https://wiki.ubuntu.com/DebuggingUpdateManager

[18:47] <bdmurray> You'll see there is a how to file section, there we have instructions
about which log files we need if your bug is about upgrading from one release to another

[18:47] <bdmurray> Providing information like that makes your bug report much more complete

[18:49] <bdmurray> And a bug report with more relevant information is more likely to get
fixed!

[18:49] <bdmurray> QUESTION: If you wanted to report a bug, but are unsure what the bug is
for (ex: it could belong to one of many programs) how would you know what package to file it
under?

[18:50] <bdmurray> Toadinator: early I mentioned the wiki page
https://wiki.ubuntu.com/Bugs/FindRightPackage

[18:51] <bdmurray> This contains some high level information about when an application is
running

[18:51] <bdmurray> For example when your system boots and you see the "Ubuntu" logo that is
the usplash package

[18:52] <bdmurray> Also printing bugs should generally be reported about cupsys and then they
will be moved to the proper package if necessary

[18:53] <bdmurray> Additionally, there is information about how to find out what application
an open window belongs to

[18:53] <bdmurray> < gscholz> QUESTION: Coming back to apport, how do you include the
functionality into an applications menu (report a problem)? Do you write a patch against the
source code? I guess these are no upstream features, or is this a kind of generic GNOME
functionality? How do you select the applications worth this feature?

[18:55] <bdmurray> The functionality of apport is integrated into an application via the
package 'liblaunchpad-integration1'

[18:56] <bdmurray> And I'm fairly certain this is a patch that Ubuntu carries for the package
with that integration

[18:56] <bdmurray> Any more questions?

[18:58] <bdmurray> Okay, then thanks for coming to the class on How to Report bugs

[18:58] <bdmurray> If you need any help reporting a bug please come to the #ubuntu-bugs
channel on freenode

[18:58] <bdmurray> Thanks!

Ubuntu Open Week - Reporting Bugs - Brian Murray - Sat, May 3, 2008

see also [:MeetingLogs/openweekhardy/ReportBugs1:Monday session]. https://bugs.launchpad.net/ubuntu/+source/reportbug-ng/+bug/175508 need to be fixed before presentation of the tool !

=== jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Reporting Bugs" - Brian Murray

[17:58] <jcastro> ok, next up is Reporting Bugs with Brian Murray

[17:59] <jcastro> this session was done on Monday but we scheduled one today to get maximum participation!

[17:59] <bdmurray> Hi, I'm Brian Murray and I'm Ubuntu's bug master.

[18:00] <bdmurray> I'm here to talk today about how to report bugs about Ubuntu as there are various ways you can do it.

[18:00] <bdmurray> Additionally, I'll cover how to make your bug report more complete and therefore more likely to get fixed!

[18:00] <bdmurray> Perhaps you are wondering what exactly is a bug?

[18:01] <bdmurray> In computer software it is an error or a flaw that makes it behave in ways for which it wasn't designed.

[18:01] <bdmurray> Some of these can result in crashes, others may have a subtle effect on functionality, others can be spelling errors.

[18:01] <bdmurray> By reporting these issues you can help to make Ubuntu even better than it already is.

[18:02] <bdmurray> Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu.

[18:02] <bdmurray> Let's look at a sample bug report - http://launchpad.net/bugs/222278.

[18:03] <bdmurray> There are 4 things there that I want to point out.

[18:03] <bdmurray> 1) The bug's title or summary is 'upgrade hanges in checkViewDepends()'

[18:04] <bdmurray> 2) In the affects table, below the title, you'll see that this bug report affects 'update-manager (Ubuntu)'

[18:04] <bdmurray> This is the package / application which the bug is about

[18:04] <bdmurray> 3) Below that is the bug's description, labelled "Bug description" ;), which is filled out when you are reporting a bug

[18:05] <bdmurray> 4) You'll also notice that there are 5 comments, 4 of which contain attachments with supporting information about the bug.

[18:05] <bdmurray> So, that's what a bug report looks like. Are there any questions about the format of a bug report or what a bug is?

[18:07] <bdmurray> < wolfger> QUESTION: if something is behaving as designed, but we don't like it, is it bug report material?

[18:08] <bdmurray> Yes, that is a valid bug however it is ultimately up to the developers of that particular piece of software whether or not they will fix it.

[18:09] <bdmurray> < smeg0l> QUESTION when do determine if it's a hardware faily or a bug ?

[18:10] <bdmurray> Determining whether or not a bug report is due to faulty hardware can be quite tricky.

[18:11] <bdmurray> Most of those bug reports would be about the kernel and by looking at kernel log files we can help you determine whether or not it is a hardware or software issue.

[18:11] <bdmurray> Moving on - How can bugs be reported to Launchpad?

[18:12] <bdmurray> They can be reported via the web interface at https://bugs.launchpad.net/ubuntu/+filebug where you start by filling out the summary which becomes the bug's tile.

[18:12] <bdmurray> After which you are asked for the package affected and for 'Futher information' which becomes the bug's description.

[18:12] <bdmurray> The description should contain at a minimum the following:

[18:13] <bdmurray> 1) The release of Ubuntu that you found the bug in.

[18:13] <bdmurray> This is important as there is more than 1 supported release of Ubuntu out there right now.

[18:13] <bdmurray> 2) The version of the package you found the bug in.

[18:14] <bdmurray> 3) The behaviou that you expected to happen

[18:14] <bdmurray> and 4) What happened instead

[18:14] <bdmurray> You also have the opportunity to add an attachment to your bug when you are reporting it via the web interface.

[18:15] <bdmurray> Another way to report a bug is using apport an automated problem report application included with Ubuntu.

[18:15] <bdmurray> The advantage to using apport is that it automatically collects information about the release of Ubuntu you are using and the version of the package / application that you are reporting the bug about.

[18:15] <bdmurray> Let's say that you have encountered a bug with Firefox.

[18:15] <bdmurray> You can use apport to report the bug by going to Firefox's "Help" menu and choosing "Report a Problem".

[18:16] <bdmurray> Apport will start collecing information about your bug and then open a new window where you enter the bug's summary / title and then enter the bug's description.

[18:17] <bdmurray> Let's look at a bug reported using the "Report a Problem" menu item

[18:17] <bdmurray> http://launchpad.net/bugs/223455

[18:17] <bdmurray> At the bottom of the description you'll see information regarding the DistroRelease, the package and version, and kernel version among other things.

[18:18] <bdmurray> All of this information is gathered for you automatically.

[18:18] <bdmurray> The "Report a Problem" functionality has been integrated into lots of applications and is the preferred way to report a bug.

[18:19] <bdmurray> Additionally, apport has a command line interface, called apport-cli, where you can report a bug about a specific package via 'apport-cli -f -p PACKAGE' which is useful for non GUI applications.

[18:19] <bdmurray> Additionally, you can also specify a process id number via 'apport-cli -f -P PID'.

[18:19] <bdmurray> Further information about reporting bugs can be found at https://help.ubuntu.com/community/ReportingBugs

[18:20] <bdmurray> Are there any questions about how you can report a bug?

[18:21] <bdmurray> < lyzium> Question: can apport initialise outside given example. If firefox crashes on start you are unable to launch the "report a problem" option

[18:21] <bdmurray> In that case you could use apport-cli -f -p firefox-3.0 for example

[18:22] <bdmurray> Also when you are running a development release of Ubuntu apport will watch for application crashes and report those

[18:23] <bdmurray> < Lardarse> QUESTION: Do you find that the differences between the developer's definition of a bug (to quote you: "an error or a flaw that makes it behave in ways for which it wasn't designed") and the end-users definition (to word it in the same way, it's usually something along the lines of "an error or a flaw that makes it behave in ways that don't make

[18:23] <bdmurray> sense") cases problems for you and for lthe other people inv

[18:24] <bdmurray> Ubuntu is designed for "human beings" and if an application behaves in a way that doesn't make sense then their is something wrong.

[18:25] <bdmurray> Possibly there is a bug in the documentation or the software's description.

[18:26] <bdmurray> That bug report won't have as a high of priority as a crash report or other bugs but it still is a valid bug.

[18:26] <bdmurray> So how can we make our bug reports more useful for developers?

[18:26] <bdmurray> Choosing the name of the package or application the bug is about is critical.

[18:27] <bdmurray> If a bug does not have a package assigned to it is much less likely to get looked at by anyone let alone the developer of that application.

[18:27] <bdmurray> Some helpful hints for finding the proper package are at https://wiki.ubuntu.com/Bugs/FindRightPackage

[18:27] <bdmurray> This page also contains the names of packages that might be hard to discover.

[18:27] <bdmurray> For example, bugs about the kernel in Hardy Heron should be reported about the 'linux' package.

[18:28] <bdmurray> Additionally, members of the Ubuntu bug squad are available in the #ubuntu-bugs cahnnel if you need help identifying the proper package.

[18:29] <bdmurray> After the bug is reported in Launchpad an important part of its life cycle is it entering the Confirmed status.

[18:29] <bdmurray> Pedro will talk about this more in the next class, but when a bug is Confirmed it means that someone has been able to recreate the bug or believes sufficient information has been included in the bug report for a developer to start working on it.

[18:29] <bdmurray> Any Launchpad user can confirm a bug report, but please don't confirm your own!

[18:30] <bdmurray> This will make the Confirmed status less useful.

[18:30] <bdmurray> What this means is that you should include extremely detailed steps to recreate the bug in it's description so anyone, not just a developer, could confirm it.

[18:31] <bdmurray> Let's take OpenOffice for example, there are phenomenal amount of things you can do in the Word Processor or the Spreadsheet parts of it.

[18:31] <bdmurray> And not every bug triager may now all the intricacies of that application.

[18:32] <bdmurray> So by putting extremely detailed steps in your bug report you are increasing the chances of it being confirmed.

[18:32] <bdmurray> It is far better to have too much detail than not enough!

[18:33] <bdmurray> Some fairly simple things you can do to make your report easier for someone to confirm are including a screenshot.

[18:33] <bdmurray> Or you can create a screencast, a movie of your desktop, using an application like istanbul.

[18:34] <bdmurray> Let's take a look at http://launchpad.net/bugs/212425

[18:34] <bdmurray> This bug has a screencast attached to it

[18:35] <bdmurray> Their description of how to reproduce the bug is pretty good but is a little hard to understand

[18:36] <bdmurray> By watching the screencast though, bug triagers are able to clearly see what steps we should take to recreate the bug.

[18:37] <bdmurray> Are there any more questions at this point in time?

[18:38] <bdmurray> < BonesolTeraDyne> QUESTION: Are there any plans to make a KDE version of Apport, or to at least give the KDE crash handler some sort of LP integration?

[18:40] <bdmurray> There are some crash reports about KDE applications reported by apport.

[18:41] <bdmurray> In regards to integration with the KDE crash handler, I'm not certain but will look into it.

[18:42] <bdmurray> One of the best ways to make your bug report more likely to be fixed is to follow the debugging procedures for the package or subsystem your bug is about.

[18:44] <bdmurray> Bug triagers and software developers have written up a variety of these debugging procedures.

[18:44] <bdmurray> A list of them can be found at https://wiki.ubuntu.com/DebuggingProcedures

[18:46] <bdmurray> If you look at the debugging update-manager page - https://wiki.ubuntu.com/DebuggingUpdateManager

[18:47] <bdmurray> You'll see there is a how to file section, there we have instructions about which log files we need if your bug is about upgrading from one release to another

[18:47] <bdmurray> Providing information like that makes your bug report much more complete

[18:49] <bdmurray> And a bug report with more relevant information is more likely to get fixed!

[18:49] <bdmurray> QUESTION: If you wanted to report a bug, but are unsure what the bug is for (ex: it could belong to one of many programs) how would you know what package to file it under?

[18:50] <bdmurray> Toadinator: early I mentioned the wiki page https://wiki.ubuntu.com/Bugs/FindRightPackage

[18:51] <bdmurray> This contains some high level information about when an application is running

[18:51] <bdmurray> For example when your system boots and you see the "Ubuntu" logo that is the usplash package

[18:52] <bdmurray> Also printing bugs should generally be reported about cupsys and then they will be moved to the proper package if necessary

[18:53] <bdmurray> Additionally, there is information about how to find out what application an open window belongs to

[18:53] <bdmurray> < gscholz> QUESTION: Coming back to apport, how do you include the functionality into an applications menu (report a problem)? Do you write a patch against the source code? I guess these are no upstream features, or is this a kind of generic GNOME functionality? How do you select the applications worth this feature?

[18:55] <bdmurray> The functionality of apport is integrated into an application via the package 'liblaunchpad-integration1'

[18:56] <bdmurray> And I'm fairly certain this is a patch that Ubuntu carries for the package with that integration

[18:56] <bdmurray> Any more questions?

[18:58] <bdmurray> Okay, then thanks for coming to the class on How to Report bugs

[18:58] <bdmurray> If you need any help reporting a bug please come to the #ubuntu-bugs channel on freenode

[18:58] <bdmurray> Thanks!

MeetingLogs/openweekhardy/ReportBugs2 (last edited 2008-08-06 16:25:13 by localhost)