=== Riddell changed the topic of #kubuntu-devel to: Bug Triage Tutorial | Kubuntu Tutorials Day https://wiki.kubuntu.org/KubuntuTutorialsDay | please discuss tutorials in #kubuntu while they are running
[16:02] <txwikinger> Commonly it is used in the field of medicine, especially in the context of emergency rooms,
[16:03] <nareshov> ah
[16:03] <limac> Riddell: Can you send me a ling to your blog? i mssed it completely! thnx :D
[16:03] <txwikinger> situations, basically when limited resources must be allocated to a high number of patients.
[16:03] <darx> yes i know about that
[16:03] <darx> also triage of symptoms
[16:03] <Riddell> limac: find it on planet.ubuntu.com or planet.kde.org
[16:03] <nareshov> limac: it's on planet.ubuntu.com
[16:03] <txwikinger> there was a disaster missing -- disaster situations
[16:03] <txwikinger> yes darx
[16:03] <txwikinger> This in an analogy that also describes what we do with bug-reports.
[16:04] <nareshov> oh
[16:04] <_nix_> anyone know where I can grab the irc logs from here?
[16:04] <limac> Riddlell and nareshove: thx dudes
[16:04] <txwikinger> When they are submitted, they must be checked if the adhere to a certain standard,
[16:04] <txwikinger> contain all the necessary information that they can be fixed
[16:04] <Sanne> _nix_: http://irclogs.ubuntu.com/
[16:04] <nareshov> _nix_: press Ctrl+O if you're using Konversation :D
[16:04] <txwikinger> and be sorted and classified in order to get the right "resource" to work on it.
[16:04] <_nix_> Sanne, nareshov: thanks..
[16:05] <txwikinger> In some way someone who triages bugs is something like a facilitator or arbitrator.
[16:05] <txwikinger> You work with the reporter in order to retrieve as much information as possible.
[16:05] <john> nareshov: I missed what Ctrl-O is for
[16:05] <txwikinger> You also work with the developers for kubuntu and ubuntu
[16:06] <PJC121> txwikinger: where do we find the reporter? silly question I know...
[16:06] <txwikinger> as well as upstream distributions like KDE and debian and others
[16:06] <blueyed> PJC121: in the bug report.. its the one who reported it :)
[16:06] <raphink> hi guys
[16:06] <txwikinger> PJC you can find them in the bug report
[16:06] <kwilliam|away> txwikinger: so we're talking Kubuntu and general KDE bugs?
[16:06] <daskreech> txwikinger: reported bugs in general
[16:06] <txwikinger> kwilliam|away: Well both
[16:07] <txwikinger> Any report that might be reported against Kubuntu
[16:07] <PJC121> i see, I thought you meant a reporter as in something that saves error messages / codes on our system, oops :)
[16:07] <txwikinger> this includes often problems that are really KDE problems
[16:07] <txwikinger> yes PJC121
[16:08] <limac> where in planet.kde.org?
[16:08] <txwikinger> So the bug triage process helps to provide the information or finding out what information is needed.
[16:08] <Riddell> limac: -> #kubuntu
[16:08] <txwikinger> Due to the fact that all of this concerns people it is very important that bug triage is done with a lot of patience and humility.
[16:08] <txwikinger> There are sometimes different interests that need to be mitigated when decisions are made,
[16:09] <txwikinger> and it is always the best to be as polite as possible to everybody around
[16:09] <txwikinger> (see also Ubuntu CoC https://launchpad.net/codeofconduct/1.0.1)
[16:09] <txwikinger> Basically two sets of skills are needed
[16:09] <txwikinger> Skills to deal with people
[16:10] <txwikinger> and some technical skills that help to deal with the reports themselves
[16:10] <elisiano_> txwikinger: all in one person? :)
[16:10] <PJC121> lol
[16:10] <txwikinger> well hopefully :D
[16:10] <elisiano_> or there are some PRs and some tech guys?
[16:11] <txwikinger> elisiano_:
[16:11] <kwilliam> elisiano: I think you need people-minded geeks
[16:11] <txwikinger> I think people have strength and weaknesses, but they can work on both those skill sets :)
[16:11] <txwikinger> The bug triage happens on launchpad https://bugs.launchpad.net/
[16:11] <txwikinger> In order to be able to triage bugs effectively, you must have an account on launchpad.
[16:12] <PJC121> bookmarked
[16:12] <DFJA> How best do you go about figuring out if a bug a kubuntu-specific, or upstream?
[16:12] <txwikinger> ok... lets go directly to the triage process
[16:12] <txwikinger> There are different elements to triaging bugs
[16:12] <txwikinger> one of them is the cleaning up of the reports
[16:13] <txwikinger> Bugs are often submitted by reporters that do not understand fully the process.
[16:13] <txwikinger> On the other hand, the people working with the bugs need efficient access to the information.
[16:13] <txwikinger> Therefore it can be very important to clean up the bugs summary to soemthing that is meaningful
[16:13] <txwikinger> that in a list of reports someone already understand the main issue of every report in the list.
[16:14] <txwikinger> It can also be helpful if certain important information is added to the description of the report,
[16:14] <txwikinger> since this is the first thing after the summary one would read.
[16:14] <txwikinger> Part of this is collecting more information about a problem
[16:15] <txwikinger> The goal is to have enough information to reproduce the problem
[16:15] <txwikinger> This is in my opinion the most important step of bug triage.
[16:15] <kwilliam> what if its hardware related?
[16:15] <kwilliam> e.g. specific video cards
[16:15] <PJC121> do you have an example problem txwikinger?
[16:15] <txwikinger> That makes it sometimes tricky kwilliam
[16:15] <txwikinger> yes.. I have one in a minute
[16:15] <PJC121> ok :)
[16:16] <txwikinger> kwilliam.. hopefully others have the same hardware
[16:16] <kwilliam> txwikinger: ok
[16:16] <txwikinger> or it has to be described very well and tested by the reporter when the fix is there
[16:16] <daskreec1> Or different hardware as the cse might be :)
[16:16] <txwikinger> In an ideal world, a bug report has a description that allows anybody following it to immediately reproduce the bug.
[16:16] <txwikinger> That is not always possible, but a good target.
[16:17] <txwikinger> It is good practice to see if the description given is sufficient to reproduce or see the problem and if necessary add additional information if the problem is found.
[16:17] <txwikinger> (Example: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979)
[16:17] <ubotu> Launchpad bug 102979 in ubiquity "[kde-ui] next button does not respond to keyboard" [Undecided,Confirmed]
[16:17] <txwikinger> this is a good example
[16:17] <txwikinger> The report was submitted and is already very good and accurate
[16:18] <txwikinger> However, when I tested it, I found a workaround and therefore valuable information for the developer to fix it
[16:18] <txwikinger> If you look at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/102979/comments/2,
[16:18] <ubotu> Launchpad bug 102979 in ubiquity "[kde-ui] next button does not respond to keyboard" [Undecided,Confirmed]
[16:18] <txwikinger> I had gone through the steps in the description and found actually a workaround for the problem.
[16:18] <txwikinger> I have added this information and confirmed that there is really a problem, that anybody can reproduce.
[16:18] <txwikinger> Often this steps includes to ask the right questions to the submitter that allows them to give more accurate information that is needed.
[16:19] <dthacker> txwikinger: you could use one I did this morning and tell me what else I should have done? 175684
[16:19] <txwikinger> bug 175684
[16:19] <ubotu> Launchpad bug 175684 in dolphin "dolphin does not keep selected file on dir list update" [Undecided,Confirmed] https://launchpad.net/bugs/175684
[16:20] <txwikinger> well, I would test it if I can 1) reproduce it
[16:20] <dthacker> I confirmed with a test
[16:20] <kwilliam> dthacker: I can try running kde4daily
[16:20] <txwikinger> secondly, I would go a little bit out of the scope to see what similar things do
[16:20] <cheguevara> i am sure that bug is true actually
[16:20] <cheguevara> lets see in kde 4
[16:21] <txwikinger> what happens when you push a different button, icon etc...
[16:21] <txwikinger> Get a little broader picture
[16:21] <cheguevara> yep same in kde 4
[16:21] <dthacker> so perhaps, what happens if a selected file is deleted, updated etc
[16:21] <txwikinger> If it gives good information for the developer
[16:21] <txwikinger> yes that are good ideas
[16:21] <txwikinger> Often it is just "playing" a little around with it
[16:22] <txwikinger> ok lets move on
[16:22] <txwikinger> Now we want to sort the bugs
[16:22] <wolfger> now dolphin has two packages, right? "dolphin" and "d3lphin"?
[16:22] <txwikinger> Often there is no package assigned or the wrong package
[16:22] <txwikinger> we want to correct that as soon as we know which package is the right one
[16:23] <txwikinger> This allows the right people to look at the bugs. Here are good instructions on how to find the right package to assigne a bug to:
[16:23] <txwikinger> https://wiki.ubuntu.com/Bugs/FindRightPackage
[16:23] <txwikinger> Furthermore we want to assign the right state to the report
[16:23] <txwikinger> https://wiki.ubuntu.com/Bugs/CommonTasks#head-6e435bd3f0413458778d4688ea2f4983e90e6ab4 gives an overwiew of the different states a report can have. For the triage, the essential states are New, Incomplete, Confirmed and Invalid.
[16:24] <thefoxx> hello
[16:24] <txwikinger> Every report start with the state New. When somebody starts to triage it and more information is necessary it will be set in the state incomplete until all the information is in the report.
[16:24] <kwilliam> dthacker: i can't reproduce it. chat after this panel over?
[16:24] <txwikinger> When all the information is in the report and the bug can be reproduced it will be set to the state Confirmed.
[16:24] <txwikinger> A lot of reports will turn out either not to be bugs, or it is impossible to collect the necessary information that the report has a positive effect, i.e really helps to solve a problem.
[16:24] <txwikinger> Sometimes reporters will not respond for request for the information needed, and it is not feasible or possible to recreate it yourself. In these cases the state will be changed to invalid.
[16:25] <txwikinger> With all those state changes always keep in mind the consequences. We do not want to unnecessarily mark reports invalid because of laziness.
[16:25] <wolfger> what if the reporter provides the information, but you still can't recreate?
[16:25] <txwikinger> A report might contain crucial information to solve a problem, sometimes not understood to the person that triages it.
[16:25] <txwikinger> well.. hopefully someone can
[16:26] <txwikinger> Otherwise it is very possible that it is an issue rather related to the particular user/install/configuration that a general bug
[16:26] <txwikinger> Therefore, we do not close report lightly in this way. We always want to make sure the report has all the necessary information to be set for the next state.
[16:26] <txwikinger> One issue are always duplicates
[16:27] <txwikinger> While reporters are encouraged to first look for similar or identical problems in the bug tracker, it is inevidable that we get a lot of duplicate reports. Therefore a very important step during the information collection is to see if there is already another report. If this is the case, the report is linked to the original report (more here: https://wiki.ubuntu.com/Bugs/CommonTasks#head-170e00a7154fcfc87f0fc50f65bba9cff7ab27fe)
[16:27] <txwikinger> If the problem is a general problem i.e KDE we also want to report it upstream
[16:27] <txwikinger> We are working very close with the upstream distros and it is a mutual benefit for everybody to get bug fixes introduced as high upstream as possible. For Kubuntu KDE is in particular of interest. Here is an example of this https://bugs.launchpad.net/kdebase/+bug/96151
[16:27] <ubotu> Launchpad bug 96151 in kdebase "kcmclock does not change to correct location" [Undecided,Confirmed]
[16:28] <txwikinger> In such cases you either find an already existing report in the upstream bugtracker and add it to the report, or you create a new report in the upstream bug tracker and add that one. Here are the instructions how to do this https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7
[16:28] <txwikinger> Basically you choose the upstream project (KDE in this case) an add the url to the particular bug in their tracker. LP will then update periodically the state of the report in the upstream tracker.
[16:28] <txwikinger> One very good help in the tasks of bug triage are standard answers
[16:29] <txwikinger> Here are lots of such responses for various situations: https://wiki.ubuntu.com/Bugs/Responses
[16:29] <txwikinger> In particular I would like to raise the attention for this one: https://wiki.ubuntu.com/Bugs/Responses#head-6ee6466fdaac8c81274185f0316afd794d2ee0b6 This can be used when the reporter does not responds (usually within a month) to the requests for more information and the existing information does not help to reproduce the problem.
[16:29] <txwikinger> Ok.. the time is already up
[16:30] <xRaich[o]2x> thanks for the tutorial
[16:30] <txwikinger> Always remember that we are working here in a team. Therefore, we help each other. It is always good to ask questions if you are not sure how to proceed. Even for the most seasoned people it can be in tricky cases very helpful to have a second opinion. So if your are not sure about something ask somebody. I am often around on the IRC channels as txwikinger or txwikinger2 (when I am at work). Feel free to see me if I can help you.
[16:30] <PJC121> thank you for your time txwikinger, helped me get started on how to start bug reporting, gj, ty
[16:30] <kwilliam> so if we have launchpad accounts...
[16:30] <john> thanks txwikinger
[16:30] <dthacker> kwilliam: yes, ping me in #kubuntu-offtopic
[16:30] <Riddell> there's lots of Kubuntu bug reports, many of them don't get an answer
[16:30] <txwikinger> The channel for the bug is #ubuntu-bugs
[16:30] <Riddell> so help is always needed with bug triage
[16:31] <txwikinger> ok Riddell you want to take over again?
[16:31] <xRaich[o]2x> now comes the fun part ^^
[16:31] <dthacker> Is there a way to create a URL that will pull all open bugs that have to do with Kubuntu?
[16:31] <Riddell> could do, anyone want to learn about bzr?
[16:31] <thefoxx> yes me
[16:31] <dthacker> me
[16:31] <xRaich[o]2x> sure thing :)
[16:31] <wolfger> yes please
[16:31] <PJC121> go go go :)
[16:31] <thefoxx> I'm using svn right now and want to learn something about bzr ;)
[16:31] <cheguevara> thanks txwikinger
[16:32] <wolfger> i've used bzr and I want to learn about svn
[16:32] <egonw> was using git-svn, but doing the same with bzr sounds interesting
[16:32] <mzungu> please