Ubuntu Wiki

Ubuntu Open Week - Ubuntu Bugsquad + Triaging Bugs - Pedro Villavicencio - Sat, May 3, 2008

see also Monday session.

jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Ubuntu Bugsquad and Triaging Bugs" - Pedro Villavicencio
[18:59] <jcastro> ok guys, next up is pedro_ and Iulian - talking about the Ubuntu bugsquad!
[18:59] <jcastro> take it away guys!
[18:59] <pedro_> thanks jcastro!
[19:00] <Iulian> Thank you, jcastro.
[19:00] <pedro_> Hello folks my name is Pedro Villavicencio and I'm the guy behind the Ubuntu Desktop Bugs, i'm here to day with the great bugsquader Iulian to talk about our Bugsquad and how to Triage Bugs
[19:02] <pedro_> the awesome Brian Murray already talked to you on how to report good quality bugs
[19:02] <pedro_> so we're going to talk to you about the rest of the process
[19:02] <pedro_> Bugsquad first:
[19:02] <pedro_> The Ubuntu BugSquad is the first point of contact for the bugs filed about Ubuntu
[19:03] <pedro_> we keep track of them and try to make sure that major bugs do not go unnoticed by developers
[19:03] <pedro_> we do this with a process called "Triage" will talk to you about it in a minutes
[19:03] <pedro_> Working with the Bug Squad it's an excellent way to start helping out and learn a lot about Ubuntu and it's infrastructure
[19:03] <pedro_> You do not need any programming knowledge to join the team in fact it is a great way to return something to our lovely Ubuntu project if you cannot program at all
[19:04] <pedro_> we have a few points of contact
[19:04] <pedro_> a team on LP https://edge.launchpad.net/~bugsquad it's an open team, so everybody can join us
[19:04] <pedro_> so if you're interested on bugs feel free to join now ;-)
[19:05] <pedro_> we also have a mailing list https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
[19:05] <pedro_> and a couple of IRC channels
[19:05] <pedro_> where the bugs are discussed: #ubuntu-bugs
[19:06] <pedro_> and another one where the bugs are announced: #ubuntu-bugs-announce
[19:06] <pedro_> also, if you have questions over a specific project you can look https://wiki.ubuntu.com/BugSquad/Contacts to see to who you can ask about it later
[19:07] <pedro_> Ok so, Bug triage is an essential part of Ubuntu's development and consists in a list of things:
[19:07] <pedro_> - Responding to new bugs as they are filed
[19:07] <pedro_> - Ensuring that new bugs have all the necessary information
[19:08] <pedro_> - Assigning bugs to the proper package
[19:08] <pedro_> Brian already talked to you about this things so we hope you'll be filing good quality reports ;-)
[19:09] <pedro_> most of the bugs we have to deal with are not assigned to the right package
[19:09] <pedro_> and moreover not assigned to anything
[19:09] <pedro_> if you look to this list  http://tinyurl.com/32l4gd
[19:09] <pedro_> there's ~3500 reports without a package assigned to it
[19:10] <pedro_> lets keep going with the list of parts
[19:10] <pedro_> - Confirming bug reports by trying to reproduce them
[19:10] <pedro_> - Setting the priority of bugs reports
[19:10] <pedro_> - Searching for and marking duplicates in the bug tracking system
[19:10] <pedro_> - Sending bugs to their upstream authors, when applicable
[19:11] <pedro_> for this one you might want to look to https://wiki.ubuntu.com/Bugs/Upstream for instructions on how to do it
[19:11] <pedro_> - Cross-referencing bugs from other distributions.
[19:11] <pedro_> - Expiring old bugs.
[19:11] <pedro_> All of these activities help the bug get fixed and subsequently making Ubuntu even better
[19:11] <pedro_> As soon as you have done enough good triage work, you can apply to the ubuntu-bugcontrol team which is the one with more rights over the reports
[19:12] <pedro_> so basically you can see the Private reports, change the Importance of the bugs and set a couple of bug status (Triaged, Won't Fix) we will talk about both in a min
[19:12] <pedro_> the requirements for join the team are available here: https://wiki.ubuntu.com/UbuntuBugControl
[19:13] <pedro_> and the lp url is : https://edge.launchpad.net/~ubuntu-bugcontrol
[19:14] <pedro_> Bug status:
[19:15] <pedro_> We currently have 9 status, they are: New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Fix Committed, Fix Released and Won't Fix
[19:15] <pedro_> New status means that no one has triaged or confirmed the report
[19:16] <pedro_> The Incomplete status means that the bug is missing some information, for example, the steps for trigger that behavior
[19:17] <pedro_> A Confirmed is almost self explanatory, someone else than the reporter is having the same bug
[19:17] <pedro_> I guess that Brian told you this, but in case of: Please do not confirm your own reports
[19:18] <pedro_> The Triaged state is set by a member of the Ubuntu Bug Control team
[19:19] <pedro_> when they think that the bug has enough information for a developer to start working on fixing the issue
[19:19] <pedro_> If a bug was marked as Triaged and a Developer is working on fixing the bug
[19:19] <pedro_> that report needs to be marked as "In Progress"
[19:20] <pedro_> please use "In Progress" just for that, I've encounter some bugs marked as In Progress because the reporter is collecting more info because a triager asked they to do so
[19:20] <pedro_> that's wrong, so please don't do it
[19:21] <pedro_> If that developer committed the fix to a bzr branch or to another repository
[19:21] <pedro_> the reports now needs to be marked as "Fix Committed"
[19:21] <pedro_> and when the fix is released, released meaning available on a Official Ubuntu repository
[19:22] <pedro_> the status of that report needs to be changed to "Fix Released"
[19:22] <pedro_> if you have any doubt or want to know more about status, you can read about them here: https://wiki.ubuntu.com/Bugs/Status
[19:24] <pedro_> does anybody has a question regarding bug status?
[19:24] <Iulian> It seems that you missed the 'Invalid' status.
[19:24] <pedro_> ok so the bad guy the "Invalid" status
[19:24] <pedro_> go ahead Iulian
[19:25] <Iulian> This status should be used when the bug report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter.
[19:26] <Iulian> Be careful when you set this status, when a bug has the invalid status it will no longer show up in default searches.
[19:27] <Iulian> We have one question.
[19:27] <pedro_> ok
[19:27] <Iulian> <sourcercito> QUESTION: how long does it takes to be able to join the ubuntu-bugcontrol team?
[19:28] <pedro_> sourcercito: it depends on how much work you been doing, the whole process can take a few weeks
[19:29] <pedro_> for the whole process i mean, for a new triager to start doing a good triage work
[19:29] <pedro_> apply for the team and then get the membership
[19:30] <pedro_> ok so Bug Importance
[19:30] <pedro_> as i said one of the nice privileges you're going to have if you join to the bugcontrol team is set importances
[19:31] <pedro_> we currently have 6 importances
[19:31] <pedro_> Undecided
[19:31] <pedro_> Wishlist
[19:31] <pedro_> Low
[19:32] <pedro_> Medium
[19:32] <pedro_> High and Critical
[19:32] <pedro_> during your first steps into the Ubuntu Bugsquad you're probaby not going to use them
[19:32] <pedro_> but you can always ask on #ubuntu-bugs for someone to set an importance for you
[19:34] <pedro_> the Undecided one is the default for new bugs
[19:35] <pedro_> and it means that there's no sufficient information to determine the importance
[19:37] <pedro_> A Wishlist is a request to add a new feature to the programs available on Ubuntu
[19:38] <pedro_> rodolfo> QUESTION: Sometimes it's hard to describe a bug in English, specially when it's about the system behavior. In these cases, there would be better to upload a video, demonstrating the bug and how it happens. Is there any idea to make this possible?
[19:38] <pedro_> rodolfo: yes, you can do it, the more information you can provide us the better
[19:38] <pedro_> there's a program called istanbul that allow you to record things happening on your desktop
[19:39] <pedro_> and if you don't know how to explain what's happening , a video it's always a good thing
[19:40] <pedro_> ok when a wishlist request it's too complex
[19:40] <pedro_> it should rather be written as a feature specification
[19:40] <pedro_> you can read about how to write them here  https://wiki.ubuntu.com/FeatureSpecifications
[19:41] <pedro_> and also if you have some ideas that you'd like to see included on Ubuntu
[19:41] <pedro_> you can use the Ubuntu Brainstorm website
[19:41] <pedro_> http://brainstorm.ubuntu.com/
[19:42] <pedro_> where you can vote for ideas and the ubuntu developers will probably going to discuss the better ones at the Ubuntu Developer Summit
[19:42] <pedro_> so *now* is the right time to do it
[19:42] <Iulian> We currently have ~8000 ideas reported on the brainstorm website.
[19:43] <pedro_> yep so feel free to add yours or vote for one that you'd like to have on our next version
[19:43] <Iulian> Every day we get 5-10 ideas.
[19:43] <Iulian> Even more sometimes.
[19:44] <Iulian> Ok, so let's get back to the Importance of a bug.
[19:45] <Iulian> The Low importance are the bugs which affect functionality.
[19:46] <Iulian> They can be easily worked around, are the bugs that affect unusual configurations or uncommon hardware.
[19:47] <Iulian> It is a bug that has a moderate inpact on a non-core application.
[19:47] <Iulian> Medium importance:
[19:48] <Iulian> Most bugs are of medium importance. For example: it has a moderate impact on a core application.
[19:49] <Iulian> It's a bug that has a severe impact on a non-core application. You can set this importance if you have a problem with a non-essential hardware component (network card, webcam, sound card, printer, etc)
[19:51] <Iulian> High importance: This is a bug that has a severe impact on a small portion of Ubuntu users. It makes a default Ubuntu installation generally unusable.
[19:51] <Iulian> e.g: system fails to boot or X fails to start on a certain make and model of computer.
[19:51] <pedro_> <Monika|K> QUESTION: Can all of the status only be set by the Bug Team or can some status be set by other people, too, and only some are reserved to the Bug Team?
[19:52] <Iulian> All statuses can be set by everyone, except Triage and Won't Fix.
[19:53] <Iulian> You have to be a member of the Ubuntu Bug Control to set those two statuses.
[19:54] <Iulian> Ok, so, the High importance should be set only if it has a moderate impact on a large portion of Ubuntu users.
[19:55] <Iulian> The Critical importance is pretty much self-explanatory.
[19:55] <Iulian> Only set this importance if a bug has a SEVERE impact on a large portion of Ubuntu users.
[19:56] <pedro_> yes, ok if you want to work with the bugsquad we organize the Bug Days
[19:56] <pedro_> also known as Hug Days (triage a bug and get a hug)
[19:57] <pedro_> well the idea of a hug day is to work together with the bugsquad and project maintainers on a specific task, weekly we organize two hug days, Tuesdays and Thursdays
[19:58] <Iulian> <nosrednaekim> QUESTION: what about the bug status "wishlist"?
[19:58] <pedro_> first one are more general hug days, focused for example of the bugs without a package and the Thursday ones are focused on desktop related task like compiz, firefox and GNOME applications
[19:59] <pedro_> If you want to join us at Hug Days just come to #ubuntu-bugs the days I've mentioned and join the fun
[19:59] <Iulian> nosrednaekim: There is no such status, that is an importance. You set that importance if it's a feature request. Pedro just talked several minutes ago about it.
[19:59] <pedro_> yes ;-)
[20:00] <pedro_> ok so we're running out of time 
[20:00] <pedro_> everyday is perfect day for triaging so don't wait till hug day!
[20:00] <jcastro> yep, you're out of time, thanks guys!
[20:00] <Iulian> Yup, thanks everyone!
[20:00] <pedro_> thanks you all ;-)