=== zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine === Guest43651 is now known as DaZ === jackyalcine is now known as zz_jackyalcine === shang__ is now known as shang === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_jackyalcine === zz_jackyalcine is now known as jackyalcine === Quintasan_ is now known as Quintasan === jackyalcine is now known as zz_jackyalcine === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_jackyalcine === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as jackyalcine === megha is now known as baba === jackyalcine is now known as zz_jackyalcine === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_jackyalcine === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Current Session: Introduction to Bug Reporting - Instructors: phillw [16:01] Logs for this session will be available at http://irclogs.ubuntu.com/2013/02/06/%23ubuntu-classroom.html following the conclusion of the session. [16:01] Hi and welcome to an introduction to bugs [16:02] this session will run over the different types and the systems used to report them === zz_jackyalcine is now known as Jacky_ [16:02] Firstly, why report a bug? [16:03] For the testers, Often we are using the latest, unmodified alpha code for various projects during the development release [16:03] do not assume someone else will report a bug! [16:03] Another important thing to remember is that Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas [16:04] By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you must raise a bug. [16:05] With the advent of 12.04, some of automated system of checking bugs has been changed and will continue to be enhanced. [16:05] There has been blog posts about a new system 'spying' on your system and sending information to Canonical. [16:05] To briefly touch on this system.... [16:06] It is called whoopise, and reports errors to a database called daisy. [16:07] it runs in the background looking for any crash reports that get reported into your /var/crash directory. If it spots one, it goes into action. [16:07] Under its settings, it may also send additional information. [16:08] Whoopise is an ongoing and active project. Fuller details all about it can be found at https://wiki.ubuntu.com/ErrorTracker [16:08] More often, for testers, we need to manually raise a bug, such as for a failed test case. [16:09] going onto launchpad and manually creating a bug often results in a bug report that can not be actioned owing to a lack of information. [16:09] the best way to prevent this is to use the ubuntu-bug command. [16:10] It can be a bit tricky to work out to what to report the bug against... To this end, for testing of ISO's a quick list can be found at https://wiki.ubuntu.com/QATeam/Overview/Install_Bugs [16:11] So, if the error occurred whilst trying to install an iso, you would issue the command ubuntu-bug ubiquity [16:12] if you are testing an application, e.g. GClac and it failed, you would issue the command ubuntu-bug gcalc [16:13] using ubuntu-bug ensures that as much information relevant to the bug is obtained and put onto the bug report. [16:13] Again, there is a full explanation at https://wiki.ubuntu.com/Bugs/FindRightPackage [16:14] If you are unsure on what package to allocate a bug against, please feel free to ask on #ubuntu-bugs and one of the people there will be more than happy to assist. [16:15] incomplete bugs do take time up which could be better spent actually dealing with bugs. [16:15] Gema will be holding a session immediately after this introduction to explain this further. [16:16] Within the quality team, we have a brief section on the basics of bug reporting as it affects quality. This can be found at https://wiki.ubuntu.com/QATeam/Overview#Bugs [16:18] Those are the basics for bug reporting, as I understand them. Please feel free to ask any questions on bugs (basic level, not advanced!) and I will endeavour to answer them (or get some one from the bug-squad to do so). [16:20] !q [16:20] Dipan asked: ug goes to Private, what does it mean? [16:20] I'll take that one. [16:21] Usually, when a bug is marked "Private" there's some good reason for it. With a lot of segfault (crash) bugs I see, a lot of them get marked as private, either because they contain information that *could* be private or could identify your system, or similar reasons [16:21] !Q [16:23] Typically, I see this with bugs which have core dumps or tracebacks which could contain information to identify someone: passwords, account numbers, etc. fall in the category of information that needs to be "removed" from the bug before it goes to a public view. [16:24] Those private bugs are therefore exactly what they are: hidden from the public eye until someone's gotten to it and actually looked through to see if there's anything that needs removal on those bugs, and then we usually make the bug visible after such things. [16:26] Also, The bot that goes looking for duplicated bugs does not worry if the bug it is using as master is private. If this happens please go to #ubuntu-bugs and raise it with them [16:29] I hope that has answered the question, are there any more questions? [16:32] johnsgruber-l-lu asked: If I have a bug in the kernel that might affect only a few systems like mine should it be reported? [16:33] short answer? yes it should. you are not to know that it only affects 'a few' systems. there may other systems that it could also impact. [16:34] indeed. Also, for kernel bugs, *always* report a new one. It is difficult to say, a priori, if your affected system is *identical* with another in an already reported bug [16:35] if it fixed i a newer release, then there is always the chance of it getting an SRU raised for it (so that it can be applied to an exisiting release). [16:36] *if it is fixed in a * [16:40] I hope that has answered the question, are there any more questions? [16:45] Whilst we still have some time left, for discussing where 'test case' bugs should go, #ubuntu-quality is a good place to ask. [16:45] There is also one remaining bug type that I completely forgot about! [16:46] on each test case, for example, http://iso.qa.ubuntu.com/qatracker/testcases/1301/info [16:47] you will at the top a link to report a bug against the test case. This is for any spelling mistakes we make and if a test case is not following the order of carrying it out that you are seeing so that they can be edited and corrected. [16:48] it is not for reporting bugs found by using the test case. [16:50] There are 10 minutes remaining in the current session. [16:55] There are 5 minutes remaining in the current session. [16:55] Well, thank you everyone for attending, a special thanks to the people from bug-squad who attended to help answering your questions. Next up is gema who will discuss following a bug report. === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Current Session: Following a Bug Report - Instructors: gema [17:00] Logs for this session will be available at http://irclogs.ubuntu.com/2013/02/06/%23ubuntu-classroom.html following the conclusion of the session. [17:00] o/ (anyone listening can you please wave in #ubuntu-classroom-chat?) [17:01] cool, so let's get started [17:01] I'd like to thank phillw for his introduction to bug reporting, that sets us all in the right mindset imo [17:02] first of all I’d like to apologise for the misleading title of this talk, I am not just going to talk about what to do to follow up on your bugs, but also about how to raise good bugs in the first place [17:02] (please, say something in #ubuntu-classroom-chat if I am too quick) [17:02] we’ll have (hopefully) some time at the end for questions, if not, you can find me on #ubuntu-quality and ask anything any time (I am on UTC timezone) [17:03] What is a good bug? [17:03] A good bug is a bug that a developer or maintainer can read, reproduce and debug without requiring any additional information [17:03] Think of the developer/maintainer as your customer: give him all he needs without him having to ask for it. After all, a happy customer improves the odds of a productive and mutually beneficial relationship [17:04] After today's talks, I'd expect you guys to be able to raise good bugs that contain enough information for someone else to debug and possibly fix the issue [17:04] When the software doesn't behave in the way you would expect, be sure to first check any available documentation to determine whether the behaviour is intended or not. [17:04] Once you are fairly confident that the issue is indeed a bug, think about the following things; you'll need them when filing your bug report: [17:05] * Steps to reproduce: How do you make the bug appear? what do you do, where to click/what to type to reproduce it? [17:05] * Test environment: What is your hardware? Is the bug be hardware specific? Where you in an X session? What else was running on your machine? what other software is running that might interact with the software under test? [17:06] * Repeatability: does this bug occur every time I run this software or just sometimes? [17:06] If it doesn't occur always, you should determine the exact conditions that make it appear. [17:06] You should be sure that it is repeatable in some way (even if it's just 1/100 runs) [17:07] * Criticality: How bad is the bug? can people still use their systems with this bug on them or does it leave the system unusable. Are people going to lose their data if they hit this bug? [17:07] Most of the time you won’t have enough information to judge the criticality of the bug, except in two cases: [17:07] 1) security bug - e.g. if the software is leaking private/secure data, or allow crashing the whole OS (Denial-of-service), or... - this should be reported as a security issue and ping the security team in the process. In some cases this type of bug shouldn’t be made public straight away, to avoid putting people affected by the vulnerability at greatest risk. [17:08] 2) critical bug - A bug that is *NOT* a security bug, but is critical in some other way, e.g. destroys a random partition by mistake. [17:08] Other problems like typos, cosmetic fixes, etc, should likely be reported as unimportant bugs, except when they are related to explicit design requirements. [17:09] But again, that’s not for the reporter to decide, unless the reporter is part of the design team ;) [17:09] In any other cases, just don’t bother about criticality and let the developer decide. [17:10] Writing a good bug report with all the information that is required for the developer to fix [17:10] the problem is hard, but not impossible. It does, however, require some effort. [17:10] Odds are that a report that takes you 5 minutes to write is not very useful and doesn't contain all the relevant bits we discussed earlier. [17:10] !Q [17:10] !q [17:11] Dipan : QUESTION: Gema I agree with your points for good bug. But sometimes giving too [17:11] much information, also creates too much confusion. What I feel, we should give [17:11] the information according to the importance of the bug [17:11] (sorry, but bot doesn't work for me) [17:11] Dipan: it is not about giving too much information, it is about giving *the right* information [17:12] if you don't document the bug properly (not too much, not too little, it depends on the bug and the way to reproduce it), developers won't be able to diagnost it properly [17:13] If you stick to these guidelines, odds are your bugs will be fixed quicker than a bug that is missing half of the information. [17:13] Nobody likes to waste their productive time trying to get details on a problem that may or may not be there. [17:14] When a bug is poorly written, the developer cannot trust your judgement as to whether what you found was a real problem... you may have messed something up or misunderstood the intended behaviour. [17:14] Hence repeatability, environmental information, etc, are critical. The more information you provide up-front, the easier it is for both of you. [17:15] Anyone reading your bug familiar with the software should be able to get an idea of what went wrong and how it happened. [17:15] If you don't think that this is the case you might be better off trying to rewrite your bug report. [17:15] A bug report should only contain relevant information and should be clear and concise. [17:16] A list of steps, symptoms and expected results, is preferred to a long paragraph describing them. [17:16] Whenever you've raised a bug, you should keep track of it from start to finish - that is, until it is resolved. [17:16] You should be prompt in replying to any questions other people may have, in particular if they affect reproducibility. [17:16] If you stick to the guidelines I outlined before, odds are you won't have much work. [17:17] When a fix for the issue becomes available, it should be the reporter's duty to make sure it fixes the bug, and reopen if that is not the case. [17:17] The developer is the expert on the software code, but you are the expert on how the software really behaves under the conditions you are testing, so you are going to be required to provide feedback as the developer explores the problem. [17:17] Your bug report should contain enough information for the developer to understand what behaviour you expected instead and why. [17:18] One bug needs to describe one problem. [17:18] Unless agreed otherwise with the developer, for whichever exceptional reason, each bug has to be about one problem only. [17:18] Having several problems in one bug makes it unmanageable and unlikely to be fixed. [17:18] See for instance bug 746500. [17:18] https://bugs.launchpad.net/ubuntu-translations/+bug/746500 [17:19] This bug had a lot of screenshots on a pdf. [17:19] You may think is useful, but the report lacks the basic information about the version of the installer or where exactly the problem was. [17:19] It was easier for a developer to run the installer themselves than to decode what is missing from the bug. This kind of bug wastes a lot of engineering time. [17:20] Some other examples of bad bugs: [17:20] https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1110500 [17:20] https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1104683 [17:20] There are 10 minutes remaining in the current session. [17:20] When it comes to ubiquity (which is something we test for every milestone), you need to pay attention to the instructions from the developers on how to attach logs and debug: [17:21] https://wiki.ubuntu.com/DebuggingUbiquity [17:21] https://wiki.ubuntu.com/DebuggingUbiquity/AttachingLogs [17:21] $ ubuntu-bug ubiquity [17:21] does correct collection of logs, as long as it's run in (a) live system after the crash/error got reproduced or (b) in the installed system when the crash/error/bug was produced during installation. [17:21] To summarize: [17:21] - You need to know the problem and be able to describe it clearly to another person that has never seen it. [17:22] - You need to give clear steps to reproduce. [17:22] - You need to say what was the behaviour you were expecting (i.e. why you think this behaviour is a problem) [17:22] - You have to be sure the problem is reproducible and the conditions under which it is reproducible and the probability. [17:22] - You should gather all the relevant logs either using the ubuntu-bug tool or manually, e.g. dmesg, syslog, etc. [17:22] and once you finish reporting the bug make sure to follow up with the developers in case some questions arise. [17:23] Be responsive so that they know it is possible to get help from you if needed. [17:23] Make sure to test their solution so that you are satisfied it meets your expectations, or reopen the bug if not (it is easier for the developer to deal with a second fix straight away than after two weeks). [17:23] There are plenty of good bugs out there as well, this is one example of good bug in my opinion: [17:23] https://bugs.launchpad.net/ubuntu/quantal/+source/ubiquity/+bug/1056707 [17:23] and that's all I have, we can have questions if you have any [17:24] or remarks if you want to make any [17:24] can someone make the classroom unmoderated , please? [17:25] any questions? you can put them in #ubuntu-classroom-chat [17:25] There are 5 minutes remaining in the current session. [17:27] ok, I will take it as a no, we can keep discussing this in #ubuntu-quality if you think of anything later [17:27] thank you all for your time! [17:30] Logs for this session will be available at http://irclogs.ubuntu.com/2013/02/06/%23ubuntu-classroom.html === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || No Sessions Currently in Progress === jordan_ is now known as jordan === NobbZ is now known as NobbZ|away