=== 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
ClassBotLogs 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
phillwHi and welcome to an introduction to bugs16:01
phillwthis session will run over the different types and the systems used to report them16:02
=== zz_jackyalcine is now known as Jacky_
phillwFirstly, why report a bug?16:02
phillwFor the testers, Often we are using the latest, unmodified alpha code for various projects during the development release16:03
phillwdo not assume someone else will report a bug!16:03
phillwAnother 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 areas16:03
phillwBy 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:04
phillwWith the advent of 12.04, some of automated system of checking bugs has been changed and will continue to be enhanced.16:05
phillwThere has been blog posts about a new system 'spying' on your system and sending information to Canonical.16:05
phillwTo briefly touch on this system....16:05
phillwIt is called whoopise, and reports errors to a database called daisy.16:06
phillwit 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
phillwUnder its settings, it may also send additional information.16:07
phillwWhoopise is an ongoing and active project. Fuller details all about it can be found at https://wiki.ubuntu.com/ErrorTracker16:08
phillwMore often, for testers, we need to manually raise a bug, such as for a failed test case.16:08
phillwgoing 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
phillwthe best way to prevent this is to use the ubuntu-bug command.16:09
phillwIt 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_Bugs16:10
phillwSo, if the error occurred whilst trying to install an iso, you would issue the command ubuntu-bug ubiquity16:11
phillwif you are testing an application, e.g. GClac and it failed, you would issue the command ubuntu-bug gcalc16:12
phillwusing ubuntu-bug ensures that as much information relevant to the bug is obtained and put onto the bug report.16:13
phillwAgain, there is a full explanation at https://wiki.ubuntu.com/Bugs/FindRightPackage16:13
phillwIf 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:14
phillwincomplete bugs do take time up which could be better spent actually dealing with bugs.16:15
phillwGema will be  holding  a session immediately after this introduction to explain this further.16:15
phillwWithin 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#Bugs16:16
phillwThose 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:18
ClassBotDipan asked: ug goes to Private, what does it mean?16:20
TheLordOfTimeI'll take that one.16:20
TheLordOfTimeUsually, 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 reasons16:21
TheLordOfTimeTypically, 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:23
TheLordOfTimeThose 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:24
phillwAlso, 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 them16:26
phillwI hope that has answered the question, are there any more questions?16:29
ClassBotjohnsgruber-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:32
phillwshort 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:33
hggdhindeed. 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 bug16:34
phillwif 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:35
phillw*if it is fixed in a *16:36
phillwI hope that has answered the question, are there any more questions?16:40
phillwWhilst we still have some time left, for discussing where 'test case' bugs should go, #ubuntu-quality is a good place to ask.16:45
phillwThere is also one remaining bug type that I completely forgot about!16:45
phillwon each test case, for example, http://iso.qa.ubuntu.com/qatracker/testcases/1301/info16:46
phillwyou 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:47
phillwit is not for reporting bugs found by using the test case.16:48
ClassBotThere are 10 minutes remaining in the current session.16:50
ClassBotThere are 5 minutes remaining in the current session.16:55
phillwWell, 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.16:55
=== 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
ClassBotLogs 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
gemao/ (anyone listening can you please wave in #ubuntu-classroom-chat?)17:00
gemacool, so let's get started17:01
gemaI'd like to thank phillw for his introduction to bug reporting, that sets us all in the right mindset imo17:01
gemafirst 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 place17:02
gema(please, say something in #ubuntu-classroom-chat if I am too quick)17:02
gemawe’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:02
gemaWhat is a good bug?17:03
gemaA good bug is a bug that a developer or maintainer can read, reproduce and debug without requiring any additional information17:03
gemaThink 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 relationship17:03
gemaAfter 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 issue17:04
gemaWhen 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
gemaOnce 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:04
gema* 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
gema* 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:05
gema* Repeatability: does this bug occur every time I run this software or just sometimes?17:06
gemaIf it doesn't occur always, you should determine the exact conditions that make it appear.17:06
gemaYou should be sure that it is repeatable in some way (even if it's just 1/100 runs)17:06
gema* 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
gemaMost of the time you won’t have enough information to judge the criticality of the bug, except in two cases:17:07
gema1) 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:07
gema2) 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
gemaOther problems like typos, cosmetic fixes, etc, should likely be reported as unimportant bugs, except when they are related to explicit design requirements.17:08
gemaBut again, that’s not for the reporter to decide, unless the reporter is part of the design team ;)17:09
gemaIn any other cases, just don’t bother about criticality and let the developer decide.17:09
gemaWriting a good bug report with all the information that is required for the developer to fix17:10
gemathe problem is hard, but not impossible. It does, however, require some effort.17:10
gemaOdds 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
gemaDipan : QUESTION: Gema I agree with your points for good bug. But sometimes giving too17:11
gema                          much information, also creates too much confusion. What I feel, we should give17:11
gema                          the information according to the importance of the bug17:11
gema(sorry, but bot doesn't work for me)17:11
gemaDipan: it is not about giving too much information, it is about giving *the right* information17:11
gemaif 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 properly17:12
gemaIf 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
gemaNobody likes to waste their productive time trying to get details on a problem that may or may not be there.17:13
gemaWhen 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
gemaHence repeatability, environmental information, etc, are critical. The more information you provide up-front, the easier it is for both of you.17:14
gemaAnyone reading your bug familiar with the software should be able to get an idea of what went wrong and how it happened.17:15
gemaIf you don't think that this is the case you might be better off trying to rewrite your bug report.17:15
gemaA bug report should only contain relevant information and should be clear and concise.17:15
gemaA list of steps, symptoms and expected results, is preferred to a long paragraph describing them.17:16
gemaWhenever you've raised a bug, you should keep track of it from start to finish - that is, until it is resolved.17:16
gemaYou should be prompt in replying to any questions other people may have, in particular if they affect reproducibility.17:16
gemaIf you stick to the guidelines I outlined before, odds are you won't have much work.17:16
gemaWhen 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
gemaThe 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
gema Your bug report should contain enough information for the developer to understand what behaviour you expected instead and why.17:17
gemaOne bug needs to describe one problem.17:18
gemaUnless agreed otherwise with the developer, for whichever exceptional reason, each bug has to be about one problem only.17:18
gemaHaving several problems in one bug makes it unmanageable and unlikely to be fixed.17:18
gemaSee for instance bug 746500.17:18
gemaThis bug had a lot of screenshots on a pdf.17:19
gema 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
gemaIt 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:19
gemaSome other examples of bad bugs:17:20
ClassBotThere are 10 minutes remaining in the current session.17:20
gemaWhen 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:20
gema$ ubuntu-bug ubiquity17:21
gemadoes 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
gemaTo summarize:17:21
gema- You need to know the problem and be able to describe it clearly to another person that has never seen it.17:21
gema- You need to give clear steps to reproduce.17:22
gema- You need to say what was the behaviour you were expecting (i.e. why you think this behaviour is a problem)17:22
gema- You have to be sure the problem is reproducible and the conditions under which it is reproducible and the probability.17:22
gema- You should gather all the relevant logs either using the ubuntu-bug tool or manually, e.g. dmesg, syslog, etc.17:22
gemaand once you finish reporting the bug make sure to follow up with the developers in case some questions arise.17:22
gemaBe responsive so that they know it is possible to get help from you if needed.17:23
gemaMake 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
gemaThere are plenty of good bugs out there as well, this is one example of good bug in my opinion:17:23
gemaand that's all I have, we can have questions if you have any17:23
gemaor remarks if you want to make any17:24
gemacan someone make the classroom unmoderated , please?17:24
gemaany questions? you can put them in #ubuntu-classroom-chat17:25
ClassBotThere are 5 minutes remaining in the current session.17:25
gemaok, I will take it as a no, we can keep discussing this in #ubuntu-quality if you think of anything later17:27
gemathank you all for your time!17:27
ClassBotLogs for this session will be available at http://irclogs.ubuntu.com/2013/02/06/%23ubuntu-classroom.html17:30
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!