02:00:01 #startmeeting How to File Bugs 02:00:01 Meeting started Tue Dec 8 02:00:01 2009 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 02:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 02:00:12 #meetingname how-to-file-bugs 02:00:12 The meeting name has been set to 'how-to-file-bugs' 02:00:17 #topic Introduction 02:00:33 #topic Introduction 02:01:03 Hello everyone. My name is Kevin Fenzi, and tonight I will be giving a short class about Bugs and how to file them in fedora. 02:01:13 Feel free to ask questions as we go or save them up for the end. 02:02:12 #topic Why Should you report Bugs? 02:02:47 The first question of course that comes up is: why should you report bugs? Perhaps someone else reported it? or it will get fixed by the developer for some other reason. 02:03:31 This gets back to one of the reasons to use Fedora. It's free and open. The bug you report could help out 100 others who see this same bug. 02:04:02 Reporting bugs is also becoming easier than ever, so the barrier is lowering all the time. 02:04:46 Some bugs only occur in specific setups or with specific hardware. If you don't report the bug, the developers may never know it's happening, and it may turn out to be easy to fix. 02:05:12 Reporting bugs is a good way to get involved in Fedora and help out. 02:05:52 #topic What is a bug? What should I report? 02:06:22 So, the next question is: what is bug worthy? What kind of things should you report and what kind are not worth reporting? 02:06:44 First of all: did it produce an error? Most software is pretty good about printing out or providing an error when it fails. 02:07:03 Some GUI programs you can run in a terminal and see if the produce any error output there. 02:07:23 Next: did it crash or otherwise become non responsive? Thats likely a good thing to report. 02:07:51 Did it do something unexpected? Like a close button that doesn't close what it's supposed to, etc. 02:08:02 Those are all report worthy. 02:09:17 What things are not? Anything to do with adding support for non free software (Fedora doesn't include such things). Large feature requests should be reported, but to the upstream project, not usually to fedora itself (unless the item is directly made by fedora). 02:09:32 which leads into the next topic: 02:09:45 #topic When to report to Fedora and when upstream 02:10:20 Fedora packages and integrates a lot of free software. Most of this software has what we call "upstream" projects. 02:10:43 So, for example the KDE desktop has a active upstream community that develops and works on their desktop. 02:11:26 In general it's good to report bugs against the package in fedora and the maintainer will let you know if thats more a matter for upstream or if they can work on it. 02:11:52 In some cases they will ask you to report it upstream so you can work with the upstream project on the issue (since you know it and see it) 02:12:17 Sometimes it will be something the Fedora packager can fix and tell upstream about, or pass your bug report on upstream. 02:12:39 ok, next lets move on to some more details on bug reporting... 02:12:45 #topic Bugzilla 02:13:20 Fedora uses bugzilla to report and manage bugs. 02:13:44 You can find bugzilla at https://bugzilla.redhat.com/ 02:14:38 You can read bugs without an account, but in order to file new bugs or comment you will need to register a new account. 02:15:17 In order to do so, you will need to give a valid email address. 02:15:47 This is so that you can get comments from bugs you post. This is very important to allow maintainers to ask you questions and get additional information on your bug. 02:16:13 bugs go through a life cycle. 02:16:19 You can see this at: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow 02:16:45 There's a flow chart there that describes what happens over time to a bug... from new report to closed. 02:17:20 Some bugs don't go through all the steps, it just depends. 02:17:36 any questions on anything so far? 02:18:08 ok, moving along... 02:18:32 #topic Checking to see if your issue has already been filed 02:19:14 The first thing you should do when you are ready to report a bug is to check and see if it's already been reported by someone else. 02:19:21 There's a few ways to do this. 02:19:48 First of all, you can check the common bugs for your Fedora release. It might be something lots of people have hit and been noted on the common bugs page. 02:19:59 https://fedoraproject.org/wiki/Common_F12_bugs 02:20:04 for example for F12. 02:20:38 Any bugs that have had a lot of reports or otherwise seen a lot will be noted there. 02:20:50 You can see that there are links there to bugzilla bug reports. 02:21:28 Secondly: If you know the package that is involved in your bug, you can look at a summary of all open bugs on that package. 02:21:44 You can do this easily with: http://bugz.fedoraproject.org/ 02:22:11 You can also use this page to report bugs (we will get to that in a bit here). 02:23:17 Third: you can use bugzillas 'simple' search form. 02:23:42 https://bugzilla.redhat.com/query.cgi 02:24:04 This will allow you to type in some search terms related to your bug... for example, if it had a error message you could search on that. 02:24:26 You can also try a google search for your bug with error terms and package name. 02:24:34 redhat bugzilla is also indexed by google 02:25:12 Lastly, there is a 'advanced' bugzilla search. This allows you to specific exact package name, version, etc. 02:25:28 If you know all those details you can try it, but it's often too targeted and complicated to tell much. 02:26:28 Note also that bugzilla.redhat.com is used for other items like RHEL or other Red Hat projects. You will want to make sure to specify the product as "Fedora" 02:26:59 Any general questions on looking to see if your bug is filed? 02:28:09 #topic Abrt 02:28:34 In Fedora 12 a new package is installed by default: abrt. 02:29:05 Abrt runs in the background and looks for crashes. Either in the kernel, or scripts, or programs of any kind. 02:29:35 when it sees something crash, it tries to gather needed info about the package and generates a bug report for you (If you tell it to do so). 02:30:19 Versions that shipped with f12 when it was first released had a few issues, so I would recommend you make sure and update it to the latest version available now. 02:31:19 When abrt detects a crash it shows a little icon in your system tray... it's a flashing red light with a ! in it. 02:31:43 If you click on that it will bring up a list of crashes it's found, and what package they are in (if it can tell). 02:32:03 Clicking on a crash then asks you for your bugzilla login and password and asks you some information. 02:32:31 It's very important to enter here what you were doing when the program crashed. That information is very helpfull to track down what went wrong. 02:33:20 Add any other info you can think of... if you have seen it crash before, etc. 02:33:50 Any questions on Abrt? It's a handy tool, hopefully it will help in reporting common bugs. 02:34:47 ok, moving along. ;) 02:35:03 #topic What information to include in a bug report 02:35:25 Much of the information I have been going over is available at: https://fedoraproject.org/wiki/Bugs_and_feature_requests 02:35:50 Also there is a section of links about Specific types of bugs and information they require. 02:36:02 Some packages need specific info to help track them down. 02:36:54 This would include things like: kernel bugs, selinux issues, sound bugs, X (display/video) bugs, anaconda (installer), and libvirt bugs. 02:37:23 These packages need extra info. For example for X bugs you want to include a copy of /var/log/Xorg.0.log and your xorg.conf (if you have one) 02:37:38 anaconda (the installer) can file bugs directly when it crashes. 02:37:52 See the above page for the particulars of each area. 02:38:02 For all bugs you want to include: 02:38:23 The version(s) of any packages involved. This is the entire version from a 'rpm -q packagename' 02:38:48 Provide info on exactly what you were doing, what you expected to happen and what did happen. 02:39:25 Any error output from the program. As mentioned eariler, you might run a GUI app from a terminal and capture any info it prints there. 02:40:31 If you are a developer type or handy with debuggers and the problem is a crash, you could get a stack trace with gdb. Note that abrt will gather this if you are using f12 or later. 02:41:00 If you know of or have found a workaround for the issue, you should also note that in the bug. It may help the maintainer track down the problem. 02:42:28 this leads into the next little section: 02:42:44 #topic Feature requests / RFE / Enhancements 02:43:06 You can also file a bug on a package about a feature request or enhancement you would like to see. 02:43:32 Many times this is something the Fedora maintainer would need to push to upstream or ask you to do so, but you can file it in Fedora's bugzilla too. 02:44:07 Note that if you are doing this, You should preface your bug summary with 'RFE' and add to the Keywords: field "FutureFeature" 02:44:37 Adding the keyword will keep your bug from some housekeeping that happens to real bugs that feature requests/enhancements should not need. 02:45:24 As an additional note, when filing a new bug, I personally like the name of the package in the front of the summary... for example: 02:45:57 xfdesktop: version x.y crashes when X and Y 02:46:11 This allows you to quickly see what the bug is against and some general info on it. 02:46:32 Summaries like "Bug in package" or "crashes" are too generic and should be avoided. 02:47:01 #topic Providing Feedback / Care and feeding of your bugs 02:47:32 Once you report a bug, a mail will be sent to the packages maintainer(s). 02:47:56 In some cases, they have a lot of bugs to deal with, so it may be a while before they get to yours. Please be patient. 02:48:06 Some things you can do however: 02:48:15 1. If anything changes, please update the bug. 02:48:36 Perhaps you find a workaround, or a new update fixes the issue or changes it. Or you isolate what exact version the problem appeared in. 02:48:47 All of those you should note on the bug as you find them out. 02:49:05 If there is a new version that doesn't fix the bug, note that too. 02:49:33 If the maintainer adds a comment asking for more info, try and provide that info for them. 02:49:50 Anytime the bug is updated you should get an email from bugzilla with any new comments or changes. 02:51:03 You may get an email that your bug was "triaged". 02:51:41 This basically is work done by the fedora BugZappers. They check your bug and see if you have the right info and package name/versions and so forth and mark it ready for the package maintainer to look thru. 02:51:58 If you're asked for more info by a BugZapper, please provide it. 02:52:13 #topic Testing Fixes 02:52:41 You may be asked by a package maintainer to test a fix for your bug, or may see a comment added by the fedora updates system that a update might fix your bug. 02:53:36 In the case of a package maintainer, they may provide you with a "scratch build" link. This is a non official build they have done in the build system. It should have links to rpm files there you can download and update the current package with. 02:54:00 In the case of the updates system the comment will include a link to a page that shows builds you can download and update with. 02:54:23 If you test a package from the updates system, you can also go provide "karma" saying it worked for you or failed somehow. 02:54:38 Please do this in addition to commenting on the bug that the test update worked. 02:55:37 Sometimes a maintainer will tell you that they have a fixed package in rawhide. This is the fedora development version. If you are not running rawhide and need a fix for a stable Fedora version, please note that in a comment to the maintainer. 02:56:09 #topic Joining in to help with Bugs 02:56:21 There are a number of ways folks can help out with bugs: 02:56:41 1. Join the bugzappers: https://fedoraproject.org/wiki/BugZappers 02:57:01 These folks look through newly filed bugs and gather info and get them ready for maintainers to look at. 02:57:20 In the cases of some packages that get lots of bugs, this is vital work. 02:57:27 It's also easy to join up and help out. 02:57:44 2. Join Fedora QA: https://fedoraproject.org/wiki/QA 02:58:15 These folks test Fedora and try and help fix up bugs before they get out to our users. Better testing here means less bugs later. 02:58:35 3. Help out maintaining packages and fixing bugs. 02:59:06 If you are developer minded, you can help out fixing bugs. Adding patches or otherwise tracking down where things are broken. 02:59:14 This is a great way to get involved in package maintaining. 02:59:28 https://fedoraproject.org/wiki/PackageMaintainers/Join has the details. 02:59:54 #topic Wrap up 02:59:56 ? How much workload is involved in each? Is it crazy to want to join both BugZappers and QA? 03:00:21 dafrito: not crazy at all. The workload is how much you want to get involved. 03:00:50 With bugzappers you usually pick some components and work on those, then add more if you have more time. 03:00:58 Some packages have very few bugs against them... 03:01:13 * dafrito nods 03:01:42 there are various areas in QA too... automated testing, testing installs, etc. 03:02:09 * nirik notes also that both bugzappers and qa have weekly meetings on irc where you can ask more detailed questions and join in. 03:02:42 ok, I think we are at the end of time here... but if anyone has any further questions on anything bug filing related, ask away. 03:04:13 ok, hopefully folks were able to listen in, and if not, we will have the archive for folks down the road. :) 03:04:16 Thanks everyone. 03:04:23 #endmeeting