Ubuntu Wiki

19:30:17 [ duanedesign] Here are some usefull bug triage links
19:30:23 [ duanedesign] ---Reporting a good bug:
19:30:23 [ duanedesign] https://help.ubuntu.com/community/ReportingBugs
19:30:23 [ duanedesign] Bug report with screen cast (possibly use Istanbul):
19:30:23 [ duanedesign] http://launchpad.net/bugs/212425
19:30:23 [ duanedesign] Finding the right package for a bug report:
19:30:24 [ duanedesign] https://wiki.ubuntu.com/Bugs/FindRightPackage
19:30:26 [ duanedesign] how to triage bugs:
19:30:31 [ duanedesign] https://wiki.ubuntu.com/Bugs/HowToTriage
19:31:36 [ ~wisd0m] hello
19:31:42 [ duanedesign] hello
19:32:17 [ ~vicky_] hello
19:32:30 [ hggdh] hello
19:32:36 [ duanedesign] wisd0m: working
19:32:44 [ duanedesign] hggdh:  you made it
19:33:05 [ ~wisd0m] no, sorry. i was just saying that i wanted to try IRC from work
19:33:08 [ hggdh] heh. I already had completely forgotten, but this time Evo did pop an alarm
19:33:09 [ ~wisd0m] i work 8-5
19:34:10 [ hggdh] a good link for bugs is https://wiki.ubuntu.com/BugSquad/KnowledgeBase
19:34:39 [ duanedesign] hggdh:  I take ityou are a member of the bug team
19:35:00 [ duanedesign] or bug control team
19:35:32 [ hggdh] yes. I am a member of both
19:36:08 [ hggdh] bugsquad is the start path
19:36:27 [ hggdh] bug-control is after you have proved experience dealing with bugs
19:36:31 [ duanedesign] what is the most common activity you engage in while triAGING. DUPLICATES, REPRODUCING, ECT
19:37:16 [ duanedesign] SPECIFICALLY BUG CONTROL TEAM CAN # Manage bug importance.
19:37:16 [ duanedesign] # See private bug reports.
19:37:16 [ duanedesign] # Set special bug statuses (Triaged, Won't Fix).
19:37:20 [ hggdh] first of all: nobody is required to look at all types of bugs. It is normal for people to set themselves on some small subset of all bugs
19:37:46 [ hggdh] I myself normally stay with coreutils and Evolution
19:37:53 [ duanedesign] small subset, you mean package
19:38:28 [ hggdh] not necessarily. For example, you can deal with KDE (any packages), or audio (any packages)
19:39:13 [ hggdh] but, to start, it is a good idea to stay with what you consider yourself good on
19:39:28 [ hggdh] so that you will be able to understand what is the problem
19:40:07 [ duanedesign] some of the responsibilities of bug triage are # Responding to new bugs as they are filed.
19:40:07 [ duanedesign] # Ensuring that new bugs have all the necessary information .
19:40:07 [ duanedesign] # Assigning bugs to the proper package.
19:40:14 [ hggdh] it should be noted that bugs are software issues; not knowing how to configure (for example) email is a question, not a bug
19:40:22 [ hggdh] that's correct
19:40:55 [ hggdh] and I would add # determining if this is a bug or a support request
19:41:12 [ duanedesign] As far as necessary info. You can learn that from filing bug how tos
19:41:45 [ duanedesign] https://help.ubuntu.com/community/ReportingBugs
19:42:00 [ duanedesign] Expiring bugs?
19:42:02 [ hggdh] there is also a cheat sheet at https://wiki.ubuntu.com/Bugs/Checklist
19:42:11 [ duanedesign] what is the expiration date
19:42:15 [ hggdh] bugs do no expire
19:42:20 [ duanedesign] ok
19:42:36 ::: vicky_ [n=vicky@192.135.141.99] has quit ["Konversation terminated!"]
19:42:50 [ hggdh] some months ago the LP (LaunchPad) team came up with bug expiration, but the outcry was too great, and they disabled it
19:43:00 ::: vicky_ [n=FrankJpL@192.135.141.99] has joined #ubuntu-us-ok
19:43:06 [ hggdh] but the messages stating it will expire are still issued
19:43:30 ::: FrankJPLang [n=FrankJpL@192.135.141.99] has joined #ubuntu-us-ok
19:43:41 [ duanedesign] when you determine a bug does not have the necessary info. you leave a comment that requests the info correct
19:43:48 ::: vicky_ [n=FrankJpL@192.135.141.99] has left #ubuntu-us-ok ["Konversation terminated!"]
19:44:08 [ hggdh] Yes. You try to explain what is missing, why it is important, and you word it NICELY
19:44:32 [ hggdh] see, for example, https://wiki.ubuntu.com/DebuggingProcedures for requirements on some packages
19:44:34 [ duanedesign] I noticed alot of them are similar
19:45:10 [ hggdh] yes, they tend to. After all, this is software, and pretty much all programs get an input, do something, and produce an output ;-)
19:45:51 [ hggdh] you should always keep in mind that the reporter is -- to the best of their intentions -- trying to help by reporting what is seem as a problem
19:46:05 [ duanedesign] what are the steps you need to take to start triaging?
19:46:15 [ duanedesign] join the bug squad?
19:46:18 [ hggdh] 1. set up a launchpad account
19:46:33 [ hggdh] 2. start hanging on #ubuntu-bugs
19:46:51 [ hggdh] 3. start tipping in bugs
19:47:19 [ duanedesign] tipping?
19:47:24 [ hggdh] 4. request bug-squad access (I think it is wide open, all you need to do is get to the page & sign up)
19:47:48 [ duanedesign] 4. does that mean join the team?
19:47:49 [ hggdh] providing your view of the issue, asking for more data, asking to be marked triaged
19:48:07 [ hggdh] yes, it does mean join the team (officially)
19:49:08 [ hggdh] you can request to join at https://launchpad.net/~bugsquad
19:49:20 [ duanedesign] since triaged can only be set by a bug control team member, you would have to ask someone in #ubuntu-bugs to mark it
19:49:55 [ hggdh] the bug-meister is Brian Murray (bdmurray)
19:50:18 [ hggdh] correct. Usually there is at least one of us hanging there, usually more
19:50:57 [ hggdh] so you go to #ubuntu-bugs, and say something like "please mark bug xxxx triaged". Be prepared to justify why
19:51:32 [ duanedesign] but you can also set the status to New, Incomplete, Confirmed, In Progress, Fix comitted, and Fix released, oh and invalid
19:51:33 [ hggdh] what will happen is one (or more) of bug-control will have a look at the bug, and may agree or have some doubts
19:52:00 [ hggdh] yes. Everyone can set a bug new, incomplete, confirmed, or invalid
19:52:23 [ hggdh] only bug-control can set it trriaged
19:52:53 [ hggdh] you should set a bug in progress if YOU are working on it to resolve the issue. In this case you should also set yourself assigned
19:53:44 [ hggdh] fix committed is set (by anyone, methinks) when a fix has been committed to the SCCS (source code control system) used for the source package
19:53:51 [ hggdh] which may be upstream
19:54:07 [ hggdh] fix released is when an Ubuntu package is released with the fix
19:55:00 [ hggdh] so -- in terms of bug work, we never set a bug In Progress (since bug work is not related to the actual fixing of the bug)
19:55:21 [ duanedesign] Incomplete status means that the bug is missing some information
19:55:31 [ duanedesign] Confirmed status is almost self explanatory; someone other than the reporter has experienced the same bug
19:55:56 [ duanedesign] In Progress. Please use "In Progress" only if a developer is working on a bug
19:56:03 [ hggdh] correct. This is where https://wiki.ubuntu.com/DebuggingProcedures comes handy
19:56:34 [ duanedesign] how do you assign yourself to a bug ?
19:56:39 [ hggdh] theoretically, the developer/maintainer working should assign the bug to herself
19:57:21 [ hggdh] click on the down-arrow for the status
19:57:36 [ duanedesign] so a triager normally would not do this
19:57:44 [ duanedesign] assign
19:57:49 [ hggdh] there you can change the package, the status/importance, and assign oneself
19:58:31 [ hggdh] normally, no, a triager does not self-assign to a bug -- unless the traiger is actively working on it (complex issues, for example)
19:58:44 [ hggdh] we tend to leave assigned bugs alone
19:58:52 [ duanedesign] what does this mean. I found it under possible things a bug might need. # Sending bugs to their upstream authors, when applicable.
19:59:11 [ hggdh] most packages are not native to Ubuntu
19:59:26 [ hggdh] (in fact, most of our packages come from Debian)
19:59:43 [ hggdh] upstream is the package origin, where the developers live.
19:59:54 [ hggdh] For example, gnome
20:00:13 [ hggdh] at http://bugzilla.gnome.org
20:00:21 [ duanedesign] would you open another bug report on http://bugzilla.gnome.org for example
20:00:28 [ hggdh] yes
20:00:32 [ hggdh] if needed
20:00:57 [ hggdh] you should first check if a similar report has already been filed, and then -- if this is the case --
20:01:13 [ hggdh] 1. add a link to the Ubuntu bug upstream (for reference)
20:01:45 [ hggdh] 2. add an "also affects project" or "also affects distribution" as needed on the Ubuntu bug
20:02:20 [ hggdh] opening upstream bugs is extremely important, since we depend on the upstream developers to fix the issue
20:02:50 [ hggdh] we may even write a patch for it (I, for example, have), but it has to be accepted upstream to be added in Ubuntu
20:03:25 [ duanedesign] I have seen those attached to peoples Launchpad pages
20:03:25 [ hggdh] in fact, the upstream connection is the second most neglected piece on bug triaging
20:03:36 [ hggdh] what do you mean?
20:03:37 [ duanedesign] the first
20:03:56 [ duanedesign] I have seen patches
20:04:04 [ hggdh] ak ok
20:04:08 [ hggdh] that can happen
20:04:27 [ hggdh] but you have to be very well known and respected for your local patch to be accepted.
20:04:38 [ hggdh] and this helps Ubuntu, but not upstream
20:04:52 [ duanedesign] under the tab personal package Archive
20:05:03 [ hggdh] oh, the PPAs
20:05:18 [ hggdh] this is a different approach that I think is unique to Ubuntu
20:05:24 [ hggdh] anyone can open a PPA
20:05:40 [ hggdh] and publish whatever package, with whatever changes one wish to make
20:05:50 [ hggdh] but... PPAs are not supported ;-)
20:06:00 [ duanedesign] I assumed you put your package there and waited to see if it would be picked up
20:06:07 [ hggdh] I have published some for Evo patches, for example
20:06:36 [ hggdh] it will never be picked up, since the PPAs are outside of the normal synaptic/apt-get path
20:06:53 [ duanedesign] what is the most neglected part of triaging
20:07:02 [ hggdh] you have to tell people that it is there, and they have to change the /etc/apt/sources.list to point to your PPA
20:07:03 [ duanedesign] assigning packages?
20:07:14 [ hggdh] no, simply triaging ;-)
20:07:20 [ duanedesign] lol
20:07:41 [ hggdh] we have hundreds to thousands of NEW bugs, waiting to be traiged
20:07:53 [ hggdh] s/trai/tria/
20:08:21 [ hggdh] bug triaging is considered the start path to work on packages, pretty much everywhere
20:08:25 [ duanedesign] do you subscribe to a feed or mailing list to hear about new bugs
20:09:02 [ hggdh] you can. If, for example, you want to know about all coreutils bugs, you can sign up for this package
20:09:08 [ hggdh] or any other you want
20:09:22 [ hggdh] I really do not recommend signing up for ALL bugs
20:09:38 [ hggdh] unless you have a LOT of empty space on disk you wish to fill up
20:09:42 [ duanedesign] high volume
20:09:51 [ hggdh] VERY high
20:10:09 [ hggdh] every action on a bug will be emailed to you
20:10:40 [ hggdh] BTW -- whenever you change a bug status, please state why
20:11:00 [ duanedesign] in the comments
20:11:16 [ duanedesign] oh i see it
20:11:17 [ hggdh] yes. When you change the status, a comment field is opened.
20:11:38 [ hggdh] but... we need help
20:11:47 [ hggdh] there are too few triagers
20:12:19 [ hggdh] I myself, most of the time, am working on a contract -- and usually I cannot keep on logged to LP the whole time
20:12:20 [ duanedesign] when you change the status. there is also an assigned too. leave that alone generally, right. that is for the developer
20:12:35 [ hggdh] or I am abroad, and cannot connect my mobile modem
20:13:03 [ hggdh] yes. Usually you will leave it as nobody (the default)
20:13:10 [ duanedesign] k
20:13:39 [ hggdh] unless -- again -- this is a complex case, and you are actively working with the reporter(s) to diagnose the issue
20:14:16 [ duanedesign] do you keep track of the bugs you have worked on
20:14:26 [ duanedesign] like the 5-a-day
20:14:43 [ hggdh] no, I do not participate in the 5-a-day
20:14:57 [ hggdh] (I do not usually have time to do 5-a-day)
20:15:04 [ duanedesign] :)
20:15:26 [ hggdh] and... I am only here tonight because I am in a hotel room, with nothing else to do, and it is 15F outside
20:15:45 [ hggdh] otherwise my S.O. will kill me
20:16:14 [ duanedesign] damn, its cold here but not that cold. where are you?
20:16:46 [ hggdh] right now i Mississauga, Canada (just by Toronto)
20:17:22 [ hggdh] and next week it is North Carolina
20:17:43 [ hggdh] be right back -- S.O. on the mobile
20:20:06 [ duanedesign] Another possibility is improving the bug report.
20:20:08 [ duanedesign] To be considered complete most bug reports must contain:
20:20:08 [ duanedesign]     * The version of Ubuntu that the reporter is running
20:20:08 [ duanedesign]     * The version of the package the reporter is using
20:20:08 [ duanedesign]     * The actions taken to produce the problem
20:20:08 [ duanedesign]     * Whether or not it is possible for the reporter to reproduce the bug
20:20:09 [ duanedesign]     * The expected result of these actions
20:20:11 [ duanedesign]     * The actual result of these actions
20:20:26 [ duanedesign] Not every bug reported contains all this information though. So as triagers we should ask for all of the above if they are missing.
20:21:06 [ duanedesign] Additionally, certain classes of bugs and specific packages require more detailed information like configuration and log files. The DebuggingProcedures page contains a list of links to detailed information to gather.
20:21:06 [ duanedesign] Since most reports probably won't be complete, you'll have to start a conversation with the bug reporter. Ask the reporter for more information by doing the following:
20:21:06 [ duanedesign]     * Click on the bug task name, which is usually the package name, in the yellow horizontal line.
20:21:06 [ duanedesign]     * Change the "Status" field to "Incomplete".
20:21:06 [ duanedesign]     * Ask for the additional information required in the "Comment on this change" field.
20:21:08 [ duanedesign]     * Click the "E-mail me about changes to this bug report" check box, so that you'll be subscribed to the bug
20:21:11 [ duanedesign]     * Click "Save changes".
20:22:32 [ hggdh] and -- anyone can subscribe to a bug -- I usually do so for the bugs I am interested in, or that I am triaging/working on
20:23:20 [ hggdh] BTW, this all may sound overwhelming... so please join #ubuntu-bugs, and ask there
20:24:03 [ duanedesign] I wanted to post the above because that sounded like at the least that was something everyone could do.
20:24:12 [ duanedesign] improve reports
20:24:15 [ hggdh] we willbe more than happy to help, discuss, and point directions
20:24:34 [ duanedesign] I am sure as we get started there will be q's
20:26:48 [ duanedesign] hggdh: I cant tell you how much I appreciate you coming to the meeting
20:27:10 [ hggdh] happy to help, duanedesign
20:27:33 [ hggdh] (I hope I did help...)
20:29:24 [ duanedesign] definetly
20:32:32 ::: hggdh [n=hggdh@216.191.216.133] has left #ubuntu-us-ok ["going away"]
20:34:12 [ duanedesign] I dont know who else is here, but Palintheus wanted me t bring up the website
20:34:32 [ duanedesign] I think he has the opportunity to host it
20:35:13 [ duanedesign] this would give us better access to the site and we would be able to more actively add content
20:36:03 [ duanedesign] the current webmaster is not nearly as active as Palintheus so I think this would be a good idea.
20:38:19 [ duanedesign] so  if anyone has any concerns please raise them either here or on the mailing list. Otherwise we will attempt to move forward with moving the hosting to the vps that Palintheus has access to.
20:40:25 [ jhalstead] New hosting sounds like the best plan.  If we're having to wait on people