1 [18:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html following the conclusion of the session.
2 [18:01] <hggdh> Hello. My name is Carlos de-Avillez. I am one of the administrators for the BugSquad and BugControl teams on Ubuntu. I have been around bugs for pretty much all my professional life -- causing them, or finding them, or fixing them (or all three in sequence ;-).
3 [18:01] <hggdh> I started with Ubuntu in 2006, when I was trying to find a Linux distribution that I felt more confortable with, and that did not need me to spend a lot of time tweaking the kernel, etc. And guess what... Ubuntu won! :-). I then joined the community, and started being active beginning of 2007.
4 [18:02] <hggdh> Now, as usual, questions should be asked on the #ubuntu-classroom-chat channel. If you want to ask a question, write it there, and precede it with 'QUESTION:'. For example:
5 [18:02] <hggdh> QUESTION: what does 'hggdh' mean?
6 [18:02] <hggdh> Let's get into the class now.
7 [18:02] <hggdh> First, who we are (https://wiki.ubuntu.com/BugSquad)
8 [18:03] <hggdh> The BugSquad is the team responsible for *triaging* bugs opened against Ubuntu and its packages. The term 'triage' is pretty much taken from medicine -- determining the priority of treatments based on the severity of a condition (see http://en.wikipedia.org/wiki/Triage).
9 [18:03] <hggdh> Different from medical triage, though, we do not expect human death as a consequence of delayed treatment.
10 [18:04] <hggdh> But we still need to triage: there are many more bugs than triagers; we have to be able to prioritise the bugs; we _should_ be able to address _all_ bugs eventually.
11 [18:05] <hggdh> For us, then, triage is the process of analysing a bug, collecting enough data to completely describe it, marking the bug 'Triaged', and give it an importance.
12 [18:05] <hggdh> Triage ends there -- it is not our responsibility to *solve* the bug: once the issue is identified, and all necessary and sufficient documentation has been added to the bug, triaging *ENDS*, and the bug goes on to a developer/maintainer to be worked on.
13 [18:06] <ClassBot> sebsebseb asked: Why do Ubuntu developers hardly ever, if ever, fix upstream bugs?
14 [18:07] <hggdh> We do... ideally our corrections/patches should be submitted to the upstream for analysis and acceptance. Sometime, though, we do not have the time or expertise to deal with it
15 [18:07] <hggdh> and we, then, rely on upstream's knowledge to solve it
16 [18:09] <hggdh> also, a lot of times we end up submitting our fixes upstream without any indication it was fixed by Ubuntu contributors -- which causes others to think we do nothing :-(
17 [18:09] <hggdh> sebsebseb, did it help?
18 [18:10] <hggdh> Back to the class: Again: triaging *ends* when a bug status is set to Triaged (see https://wiki.ubuntu.com/Bugs/Status).
19 [18:10] <hggdh> This does not mean we do not solve bugs ourselves. Most of us wear a lot of hats, on (possibly) more than one project. But _triaging_ ends when the bug is set to Triaged.
20 [18:10] <hggdh> sebsebseb, ^heh ;-)
21 [18:11] <hggdh> Now, another important point is being able to differentiate between bugs (errors in a programme/package) and support issues (how to use a programme/package, how to set up something). We only deal with *bugs*.
22 [18:11] <hggdh> Support requests should be redirected to one of the appropriate fora: http://askubuntu.com/, https://answers.launchpad.net/, http://ubuntuforums.org/, an appropriate IRC channel, etc.
23 [18:11] <ClassBot> jledbetter asked: Can anyone triage? Say, for example, I see a bug that is new can I -- random user -- 'confirm' it? Anything I can do to help?
24 [18:12] <hggdh> yes, anyone can help (and we *do* hope we will have help)
25 [18:13] <hggdh> if one can confirm a bug -- exact same scenario, reproduced/reproducible, then marking the bug confirmed will help
26 [18:13] <hggdh> also, please add a comment stating how you reached the conclusion that you could confirm
27 [18:14] <hggdh> With that in mind...
28 [18:14] <hggdh> DO: follow the advices and recommendations from jledbetter's class (that just ended): they can be used not only for finding more about your own issues, but *ALSO* for triaging somebody else's bugs.
29 [18:15] <hggdh> DO: read https://wiki.ubuntu.com/BugSquad/KnowledgeBase. Really. No kidding.
30 [18:15] <hggdh> These pages give us a summary of all we learned during all the time we worked on triaging, what can be done, etc
31 [18:16] <hggdh> DO: read the Code of Conduct (http://www.ubuntu.com/community/conduct). A nice exposition of the CoC is also at https://wiki.ubuntu.com/CodeOfConductGuidelines.
32 [18:16] <hggdh> (if you wish to be a member of the BugSquad, we require that you sign it.)
33 [18:17] <hggdh> This -- the CoC -- is perhaps the major difference between Ubuntu and other projects: we try very hard to live by it. *NOT* signing it does not free one from been required to be civil. So...
34 [18:18] <hggdh> DO: be nice. Say 'please', and 'thank you'. It does help, a lot. Follow the Golden Rule (http://en.wikipedia.org/wiki/The_Golden_Rule), *always*.
35 [18:19] <hggdh> DO: keep in mind that English is the official language on https://bugs.launchpad.net, but _many_ UBuntu bug reporters are *not* native speakers of English. This means that many times we will get bugs that are badly written in English (or not in English at all).
36 [18:20] <hggdh> DO: Try to understand. Ask for someone else to translate it if you do not speak (er, read) the language (hint: the #ubuntu-translators and #ubuntu-bug channels will probably have someone able to translate). Be nice -- always. "I cannot understand you" is, most of the times, *not* nice ;-)
37 [18:21] <hggdh> But, if you really cannot understand state something like: "I am sorry, but I cannot understand <whatever>, could you please expand on yadda yadda and so on?"
38 [18:22] <hggdh> (notice the "I am sorry", "please", etc)
39 [18:22] <hggdh> Of course, "I am sorry, but you are an <expletive> " does NOT do the trick.
40 [18:23] <hggdh> DO: ask for help on how to deal with a bug if you are unsure. Nobody knows it all, and we all started ignorant on bug triaging (and, pretty much, on everything else ;-). We have a mailing list (Ubuntu-bugsquad@lists.ubuntu.com), and we are always at the #ubuntu-bugs channel on freenode.
41 [18:24] <hggdh> We will be more than happy to help out on procedures and requirements.
42 [18:24] <hggdh> Please note that we do not _triage_ bugs there -- we will answer and help on procedures and requirements. We will, though, point out deficiencies and missing data, and suggest actions.
43 [18:25] <hggdh> DO: _understand_ the problem. A lot of times we see a bug where a _consequence_ is described, but not the _cause_. The triager should do her/his best to understand which is which, and act accordingly. This may mean changing the bug's package, or rewriting the description, etc.
44 [18:26] <hggdh> But... if we do not understand what is the problem, then how can we correct it?
45 [18:26] <hggdh> There are many ways to do that; most will require learning ;-)
46 [18:27] <hggdh> most, also have never been really ported/adapted to computing (differential diagnosis -- medicine --, fault trees -- nuclear reactors, rockets --, etc). So... right now, the best way is to learn more. To keep on learning. With time you will be able to _intuitively_ see a consequence.
47 [18:27] <hggdh> -> keep in mind that *correlation is not causation* (see http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation).
48 [18:28] <hggdh> DO: Try to ask and find answers for some questions: WHAT did happen? WHY did it happen? WHICH COMPONENTS are involved? HOW did it happen? HOW can it be REPEATED? What has CHANGED (if it worked before)?
49 [18:29] <hggdh> So... you go on, aks the questions you fell pertinent, change the bug status (to Incomplete/New/Confirmed/Whatever). Now:
50 [18:30] <hggdh> DO: add a comment on every action you take on the bug (changing status, importance, package, etc). Although for you it may be crystal-clear the reasons for taking an action, this may not be true for others (in fact, a lot of times it is not clear, at all...).
51 [18:30] <hggdh> On the other hand...
52 [18:30] <hggdh> DO NOT: add comments like "me too", "I also have it", "also a problem here", etc. These comments just pollute the bug, making it more difficult to find out what happened, where we are, and what is the next step. INSTEAD:
53 [18:31] <hggdh> DO: just mark the bug as "affects me too" (and subscribe to it, if you wish to know when the issue is resolved).
54 [18:32] <hggdh> DO: if you are starting on triage, browse the open bugs (there are about 80,000 of them) and look for one you feel _comfortable_ with (or less uncomfortable ;-). Ideally, you should be able to reproduce it. It does help if you start with bugs on packages you yourself use.
55 [18:32] <hggdh> And
56 [18:33] <hggdh> DO: get on to #ubuntu-bugs, and ask for help there when in doubt. We do not bite... :-)
57 [18:33] <hggdh> Oh, since we are here:
58 [18:33] <hggdh> DO NOT: change a Triaged bug to New/Incomplete/Confirmed -- a triaged bug is OUT OF SCOPE for triaging. It is not our problem anymore (while wearing the triager's hat).
59 [18:34] <hggdh> (or course, if I am the developer/maintainer of a package affected by a bug, I can move it out of Triaged if I understand the bug is missing critical data)
60 [18:35] <hggdh> DO NOT: assign yourself (or any other person) to a bug. Bug assignment is a clear, official, signal that "the assignee is actively working on resolving this issue". Nobody else -- including the developers/maintainers -- will touch this bug anymore. Instead...
61 [18:35] <hggdh> DO: so... if you are triaging, and have asked a question/requested action from the OP (Original Poster), *subscribe* to the bug. Nothing is worse than a fire-and-forget action.
62 [18:36] <hggdh> DO NOT: confirm your own bugs. The fact that you see/experience a bug does not necessarily _make_ it a real bug. It may be something on your setup...
63 [18:36] <hggdh> DO: follow suggested actions. For some packages we have more detailed 'howtos'. These are described under the https://wiki.ubuntu.com/DebuggingProcedures page. It is always a good idea to check them (and update/correct as needed).
64 [18:37] <hggdh> Now, a lot of the packages we offer on Ubuntu come from different projects -- Debian, Gnome, GNU, etc. We call these projects -- where real development usually takes place -- "upstream". By the same reasoning, we say we are "downstream" from them.
65 [18:37] <hggdh> The ideal scenario is we have our packages identical to what upstream provide, no local patches (except, probably, for packaging details).
66 [18:38] <hggdh> Having local changes increases the delta (the difference between what we provide and what upstream provides), and makes updates/upgrades more costly. So our patches, ideally, should be provided to the upstream project, and discussed there (and hopefully accepted).
67 [18:39] <hggdh> Bugs affecting upstream projects have to be communicated upstream. This usually means doing a similar triage as we do here for a specific upstream (looking for an identical bug on the upstream project, and opening one if none is found). So.
68 [18:40] <hggdh> DO: Look upstream, and open a new bug if needed; then *link* this upstream bug to ours (and ours to theirs).
69 [18:40] <hggdh> For example, for Gnome applications, the upstream BTS (Bug Tracking System) is at http://bugzilla.gnome.org.
70 [18:41] <hggdh> Many upstreams have different rules on how to open/work with/close a bug. Ergo,
71 [18:42] <hggdh> DO: follow upstream's processes when working upstream (in an old saying, "when you enter a community, abide by its laws").
72 [18:43] <hggdh> Please note that this goes hand-in-hand with the CoC/Golden Rule. The fact that (in my original country) I could get to the beach wearing a speedo, does not make it nice (or even accepted) in the US (where I live).
73 [18:44] <ClassBot> autif asked: absolutely silly question, bust asking just because you have not covered it in your chat - what bugs are you talking about - Ubuntu bugs? Do they include other derivatives like xubuntu, kubuntu etc? Where are the stored?
74 [18:45] <hggdh> I am talking primarily about Ubuntu bugs; but, of course, all official Ubuntu derivatives (i.e., those that have the BTS on https://launchpad.net) would be dealt in the same way
75 [18:46] <hggdh> this applies, for example, to Xubuntu, Mythbuntu, Kubuntu, etc. But some of those derivatives may have their own particular way of dealing with bugs
76 [18:47] <hggdh> IIRC, for a while (at least) Kubuntu suggested opening K* bugs directly upstream.
77 === autif1 is now known as autif
78 [18:48] <hggdh> But, even if they have special procedures, all I am stating here still applies in *full*. These DO/DONOT are really generic
79 [18:49] <hggdh> Any other questions? I am almost done...
80 [18:50] <hggdh> autif -- for some of the derivatives, you "assign" a bug to it by adding the project to the bug (for example, with Mythbuntu)
81 [18:50] <ClassBot> IdleOne asked: IF we are affected by a bug that has been open for a long time and there doesn't seem to be any work going on with it, what can we do?
82 [18:51] <ClassBot> There are 10 minutes remaining in the current session.
83 [18:51] <hggdh> First, the short answer: *help*
84 [18:51] <hggdh> Now, the longer one:
85 [18:52] <hggdh> there are many more bugs than there are triagers. We need all help we can get. So, triaging an old bug (even if on self-interest) _still_ helps
86 [18:52] <hggdh> checking upstream, opening upstream, etc. Confirming it is still present on the current Development/ or last published Stable release helps
87 [18:53] <hggdh> but, please not something like "I am tired of waiting for you slackers to get this resolved"
88 [18:53] <hggdh> This will not really help. No real new data, confirmation it still happens, etc.
89 [18:54] <hggdh> and indeed, a comment on a bug will bring it back up to those subscribed to it (I, for example, subscribe to all server packages)
90 [18:54] <hggdh> and there was a old one that has just being brought back to my attention this way
91 [18:55] <hggdh> with this said, and no more questions...
92 [18:55] <hggdh> Thank you. I am glad you were here, and I hope you help us out. And we are always (er, at least there is always someone logged it, we also have a life) available to help and discuss triaging work.
93 [18:56] <ClassBot> There are 5 minutes remaining in the current session.
94 [19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html