'''CAVEAT: Most of these processes have changed!'''

= Drinking from the Firehose - How to do Bug Triage right.. =

Simon Law (the guy in charge Ubuntu QA) discusses aspects of bug triaging and how to work with the [[http://launchpad.net/distros/ubuntu/+bugs|Malone]] bug tracking system used in Ubuntu.


{{{
< sfllaw> So, I'm not much of a teacher here.  But more of a facilitator.
< sfllaw> I want to help you get involved with bug tracking, so I don't want this to be a lecture.
< sfllaw> You guys can totally participate in the discussion.
< sfllaw> OK.  Shall we start?
< sfllaw> As I was saying, I'm not much of a teacher but more of a guide.
< sfllaw> This will be a participatory tutorial, so feel free to take the discussion into places you want it to go.
< sfllaw> We're here to talk about bugs in Ubuntu.
< sfllaw> We've got a lot of them.
< sfllaw> And because we're pretty popular, we keep on getting more every day.
< sfllaw> We manage these bugs through Malone, which is a part of Launchpad.  I'm pretty sure you're familiar with it, to some extent.
< sfllaw> But here's a nice page to look at:
< sfllaw> https://launchpad.net/distros/ubuntu/+bugs
< sfllaw> You can see that we have quite a few open bugs.  About 13775.
< sfllaw> So who looks at all of these bugs?
< sfllaw> Well, people on the development team do.  But no one person can look at all the new bugs coming through.
< sfllaw> We have a wonderful group of volunteers called the BugSquad.
< sfllaw> They hang out in #ubuntu-bugs, which I encourage you to join.
< sfllaw> And if you do hang out there, you'll notice a bot called Ubugtu.
< sfllaw> Once in a while, whenever someone files a new bug, it writes out a little message.
< sfllaw> Like: New bug reported: Malone bug 55188 in pixelize (universe) "Error opening pic_db.dat for read" [Untriaged,Unconfirmed] http://launchpad.net/bugs/55188
< sfllaw> OK, I've never looked at that bug before.
< sfllaw> But let's see if we can triage it.
< sfllaw> Let's look at the bug page.
< sfllaw> What's the first thing that pops to mind?
< Martijn81> status
< skateinmars> duplicate bug ?
< sfllaw> skateinmars: Good.  Let's check if it's a duplicate bug before we do lots of other work.
< sfllaw> On the right hand side of the screen, there's a link called "Show all open bugs".
< sfllaw> Anyone see a duplicate?
< eigenlambda> nope
< neverendingo> no
< sfllaw> Yeah.  There are only two pixelize bugs in Malone.
< eigenlambda> both open bugs were filed by the same guy, too
< sfllaw> eigenlambda: That's true.  He's probably one of the few users of this software.
< eigenlambda> maybe that package has 64-bitness problems?
< welshbyte> how do we know there isn't a dupe that's been closed and the reporter just hasn't updated?
< sfllaw> welshbyte: We can theoretically search the database for that.
< neverendingo> and what about bugs assigned to the wrong package?
< sfllaw> But normally, it isn't worth sifting through all the closed bugs.
< sfllaw> There are a lot.
< welshbyte> ok, just covering the possibilities
< sfllaw> And it could be a regression!
< sfllaw> One way is to make sure that the user is running the latest version of the package.
< sfllaw> neverendingo: That's a hard problem.
< bx> are there ever times where there is a duplicate, but the duplicate bug has already been resolved?
< sfllaw> neverendingo: If you bump into a bug assigned to the wrong package, you can change it.
< neverendingo> ok
< sfllaw> But to find duplicates that are in another package is like finding a needle in a haystack.
< ryanakca> sfllaw: I take it you find out what verson they're running by posting a comment?
< neverendingo> i think i found one some time ago
< sfllaw> ryanakca: That's right.
< ryanakca> sfllaw: or just by looking at the date of the bug report?
< sfllaw> ryanakca: We look at the bug to see if there's enough information to debug it.
< sfllaw> ryanakca: And if there isn't, we ask for things.
< sfllaw> https://wiki.ubuntu.com/HelpingWithBugs has some guides to help us with debugging.
< sfllaw> We're adding more as we go along.
< sfllaw> OK.  So we're looking at this bug and we want to ask ourselves if there's an upstream bug.
< sfllaw> So we have to find upstream.
< sfllaw> You can find it one of two ways:
< sfllaw> /usr/share/doc/PACKAGENAME/copyright
< sfllaw> Or go to http://packages.ubuntu.com and search for it there.
< ryanakca> and the first one only works if you have the package installed yourself?
< sfllaw> ryanakca: Exactly.
< bx> sorry, but can you briefly state what an upstream bug is. (noob here)
< sfllaw> bx: Great question.
< sfllaw> You can think of FOSS distribution like a river.
< sfllaw> The author of a piece of software is the initial source.
< sfllaw> You might have a project that collects this software, like the KDE project.
< sfllaw> That's a downstream project.  And the author is upstream for KDE.
< sfllaw> And then you might have a distribution like Ubuntu.
< sfllaw> That's a downstream project as well.
< sfllaw> And the author and KDE are upstream.
< sfllaw> You always want to report things upstream, or send patches upstream, because then everyone benefits.
< sfllaw> Some upstreams can get a bit huffy or unpleasant, but don't let that disuade you from doing the Right Thing.
< ryanakca> so... you end up being registered to a couple dozen bug reporting systems? because of upstream?
< sfllaw> ryanakca: Mmm.
< sfllaw> That's where Malone comes in.
< sfllaw> If they actually have a bug tracking system that Malone knows about, you can tie that in.
< sfllaw> Each bug has a "+Upstream" and "+Distribution" link.
< sfllaw> Malone will pull the status of another bugtracker once per day.
< sfllaw> And update the state of the bug.
< sfllaw> You can also add bugtrackers...
< sfllaw> If they're not already in the list.
< matid> If, lets say, software is developed on external svn server we ought to download the source, compile it and check it against the bug we try to solve?
< eigenlambda> sweet
< sfllaw> matid: You can.  But for triaging, that's not necessary.
< sfllaw> Think of it like a emergency room.
< eigenlambda> ya, you download the source codes, fix them, and tell upstream ^_^
< sfllaw> A bug comes in.  You look at it, get some data from the user that will be useful for a developer, assign a priority and move on.
< sfllaw> After that, if you want to put on your developer hat, that's super cool.
< eigenlambda> but fixes only go to edgy, not dapper -_-
< sfllaw> But the point is to divert the big flow of bugs so that people familiar with the code aren't just playing with the bug tracker all day.
< eigenlambda> priority?  i thought only maintainers were allowed to do that?
< sfllaw> Developers can do it.
< eigenlambda> or are we allowed to set a bug's priority when we get enough karma?
< sfllaw> As can people on the ubuntu-qa team.
< matid> So how do I check if a bug actually occurs in the upstream?
< ryanakca> you have to be in ubuntu-qa to do that right?
< ryanakca> yeah
< eigenlambda> oh, ok.
 * eigenlambda should probably consider joining qa then
< sfllaw> Once you work on a couple of bugs and get a feeling for priority, then dholbach or I can grant you permission.
< ryanakca> so the average person who helps out triaging couldn't set a priority... they'd have to be added to qa?
< sfllaw> It's so that people who don't know how to triage don't set their bugs to SUPER IMPORTANT PLEASE FIX NOW!!!!
< sfllaw> Which used to happen. :(
< ryanakca> couple = a bit more than a couple?
< eigenlambda> lol prolly
< ryanakca> lol
< sfllaw> A description of the meanings of these fields are found at https://wiki.ubuntu.com/Bugs/CommonTasks
< sfllaw> matid: Great.  You can do this by finding upstream.
< eigenlambda> i just want to be able to set certain bugs 'wishlist' and stuff
< sfllaw> http://packages.ubuntu.com/dapper/graphics/pixelize
< sfllaw> If you click on the copyright file...
< eigenlambda> i think people should be allowed to set their bugs to wishlist, actually
< sfllaw> You see where the software was downloaded from.
< sfllaw> http://lashwhip.com/pixelize/
< asimon> You only mentioned getting more information from the reporter and setting the priority. Is trying to reproduce the bug and setting the status to 'confirmed' not a part of the triage?
< sfllaw> asimon: It can be.
< neverendingo> i can reproduce it
< sfllaw> asimon: But lots of times, you'll be dealing with bugs that would take you a lot of time to reproduce.
< eigenlambda> ya
< asimon> Ok, so no must.
< sfllaw> asimon: Right.  If you can, that's bonus.  Then you can provide the information yourself.
< neutrinomass> eigenlambda: I agree that it would be nice if you could lower the importance of your own bugs.... maybe it should be filed as a wishlist against malone ?
< eigenlambda> i confirm bugs when i see dupes ^_^
< sfllaw> So it looks like upstream doesn't have a bug tracker.
< rodarvus> also many bugs (like architecture dependant bugs, or bugs for X.Org video drivers) can not be reproduced by everyone
< sfllaw> We'll remember this site, in case we want to e-mail the author.
< sfllaw> Which we'll do politely, because we're nice.  :)
< sfllaw> rodarvus: A LONG time.
< sfllaw> Involving saving up cash for a new video card.
< sfllaw> ;)
< rodarvus> :)
< ryanakca> yeah... being able to set your own bug to "wishlist" would be nice :)
< sfllaw> neverendingo: So you said you can reproduce it.
< neverendingo> sfllaw: yes
< welshbyte> eigenlambda: so if i want an imaginary bug confirmed quickly i should sign up to malone twice and dupe my first erroneous bug, then point you at it? ;)
< rodarvus> ryanakca, open a bug for launchpad requesting this :)
< sfllaw> Is that expected behaviour?
< sfllaw> eigenlambda: You don't want to confirm bugs when you see dupes.
< matid> If there were a bug tracker on the author's website we look for the bug in it and if it's there it means it's an upstream bug?
< sfllaw> Confirmed means that the bug has been properly triaged.
< sfllaw> And there's a good data so that a programmer can look into the bug and isolate it.
< sfllaw> It may not be sufficient.  The user might have to be bothered again.
< sfllaw> But it should be 90% good.
< sfllaw> matid: That's right.
< neverendingo> i have the same error, but no amd64
< sfllaw> matid: It also means that the bug can be confirmed, because the author knows about it too.
< sfllaw> neverendingo: OK.  I have the suspicion that this is just a bad UI.
< sfllaw> Are there manpages?
< sfllaw> What do the manpages for make_db and pixelize say?
< neverendingo> yes
< matid> Ok, I get it
< sfllaw> matid: In the upstream bugtracker, we put a comment saying "Hi!  We're Ubuntu and our user reported this problem too."
< sfllaw> Then give the Launchpad link, so that upstream can take a look if she wants to.
< sfllaw> And then we link the upstream bug to this ours, so we get status updates.
< sfllaw> (Obviously, if it's the _same_ user who reported it upstream, we don't confirm.  We ask for more info.)
< matid> Why is it necessary?
< matid> I mean asking for more info in this case.
< sfllaw> Because if it's the same user, then it's not as useful.
< sfllaw> Well, also, if the upstream bug doesn't have any dialog in it.
< sfllaw> Like the author doesn't have more info than we do, we should ask for info as well.
< matid> Ah, ok.
< sfllaw> The idea is that Confirmed bugs have enough information for someone to fix it.
< sfllaw> Typically, upstream developers pay a lot of attention to their bugs, because they're concentrating on one piece of software.
< sfllaw> neverendingo: Ping?
< welshbyte> what if the bug is fixed upstream but occurs in ubuntu?
< neverendingo> sorry?
< sfllaw> welshbyte: Then you set it to confirmed and leave a comment to that effect.
< welshbyte> ok
< sfllaw> neverendingo: What do the manpages for make_db and pixelize say.
< sfllaw> ?
< sfllaw> Do they mention how the software is supposed to work?
< matid> Who changes the status to fixed if the bug actually get fixed in the distro, after it's fixed in the upstream?
< sfllaw> http://www.penguin-soft.com/penguin/man/1/pixelize.html
< sfllaw> http://www.penguin-soft.com/penguin/man/1/make_db.html
< neverendingo> yes, but in pixelize's description theres nothing about make_db
< sfllaw> matid: The person who makes the upload into the archive.
< matid> So basically a MOTU or a developer?
< sfllaw> It looks like the manpages say you HAVE to run make_db first.
< sfllaw> matid: There are two types of Fixed.
< sfllaw> There's Fix Committed and Fix Released.
< sfllaw> Fix Released should be twiddled by people who did the uploading.
< sfllaw> Into the archive.
< sfllaw> Fix Committed is a bit iffy.
< neverendingo> but it says, that it is USED by pixelize??
< sfllaw> You can set Fix Committed can be used by package maintainers or upstream authors.
< sfllaw> Personally, I'd avoid touching that one, as different maintainers have different meanings.
< sfllaw> Of course, if you know how that flag is used for that package, go ahead and do the Right Thing.
< ryanakca> rodarvus: https://launchpad.net/products/launchpad/+bug/55195
< sfllaw> neverendingo: It looks like the documentation says pic_db.dat is the file used.
< sfllaw> Not make_db.
< sfllaw> So the bug appears, at a cursory investigation, to be a UI issue.
< sfllaw> Now, we don't reject this.
< neverendingo> ah, the helpmenu says the same as you
< eigenlambda> what does "in progress" mean?
< sfllaw> eigenlambda: https://wiki.ubuntu.com/Bugs/CommonTasks
< ryanakca> eigenlambda: I believe it means that someone is working on fixing the bug
< sfllaw> It means that someone is working on fixing the bug.
< sfllaw> ryanakca: Man, you're fast.
< eigenlambda> 'k
< eigenlambda> thought so
< ryanakca> sfllaw: lol
< sfllaw> It is an actual bug, which is why we don't reject it.
< sfllaw> But the user reported the wrong root cause.
< sfllaw> So what should we do with the bug?
< doluu> go upstream?
< eigenlambda> comment on it and tell the maintainer?
< eigenlambda> confirm and set importance?
< ryanakca> run in circles screaming that your confused and blaming the bug for everything that goes wrong in this world?
< ozamosi> Rename it?
< eigenlambda> ya rename, good idea
< sfllaw> How about editing the description?
< sfllaw> Did you know that you can do that?
< ryanakca> I'd go comment and rename
< ryanakca> you can?
 * eigenlambda thinks https://launchpad.net/distros/ubuntu/+source/sbackup/+bug/5720 should be renamed
< sfllaw> Yeah, there's an Edit Description link.
< neverendingo> the author tells in help, what to do, also running make_db first
< sfllaw> Let's edit the description.  I suppose I'll do it, because there's only one person.
< sfllaw> What's a good summary?
< ryanakca> eigenlambda: yeah... I think so too.. "/usr/sbin/simple-backup-config doesn't open after run"
< kozz> so can anybody change the description for any bug?
< sfllaw> kozz: Yup.
< sfllaw> It keeps a log of them, just like comments.
 * eigenlambda goes to change bug #1 to 'this bug has been vandalized'
 * ryanakca would hope that it's just qa... otherwise any idiot can vandalise them.. kindof like on wikis...
< sfllaw> But updating the description means that you can make an abstract or executive summary.
< sfllaw> So that you don't have to read through tons of comments to get the final result.
< sfllaw> ryanakca: Well, it keeps track of what the old descriptions used to say.
< sfllaw> So you can change them back.
< ryanakca> yeah
< sfllaw> OK.  So I've edited the bug description.
< sfllaw> https://launchpad.net/distros/ubuntu/+source/pixelize/+bug/55188
< sfllaw> I've got a title that is pretty clear.
< sfllaw> If people look for their error message, they'll find it.
< sfllaw> The description has been changed to give the root cause for the bug.
< sfllaw> And notice how Malone put the old description in the comments.
< neverendingo> nice
< sfllaw> Well, this package also comes from Debian, like many packages in universe.
< sfllaw> So let's look at http://bugs.debian.org/pixelize
< sfllaw> Is the bug there?
< neverendingo> no
< welshbyte> i'd say that pixelize should run make_db itself on first run... but that's off-topic for this lesson i guess :)
< matid> Not really
< sfllaw> OK.  I'm going to file a Debian bug.
< sfllaw> Working with Debian is pretty important for Ubuntu.
< matid> welshbyte: Or it should at least notify you that you have to run it first instead of crashing
< sfllaw> It's where we get most of our new software.
< sfllaw> So we want to give back.
< sfllaw> That helps us, and it helps them.
< sfllaw> http://www.debian.org/Bugs/Reporting
< neverendingo> matid: maybe that's a task for the developer?
< sfllaw> You can't use the reportbug tool, though.
< sfllaw> Unless you run Debian.  :)
< matid> neverendingo: It seems so
< sfllaw> OK.  I'm going to submit a bug now.
< neverendingo> what about telling the author about this misbehaviour?
< doluu> but we can run make_db by post install script, right?
< sfllaw> doluu: Uhm.  No.
< kozz> wouldn't it be better to just report it upstream instead of also reporting a bug to debian, what more can they do than reporting it to upstrem?
< matid> sfllaw: You can't commit a bug report via www in Debian, can you?
< sfllaw> neverendingo: Yup.  I'm going to do that too.
< doluu> but, why?
< sfllaw> kozz: Because Debian wrote the manpage!
< sfllaw> doluu: Because you run the command on a directory of images.
< sfllaw> matid: Sadly, no.
< kozz> sfllaw: right.. ;)
< doluu> ok, I got it
< rodarvus> sfllaw, opening the bug in debian via malone sends the email for you, doesn't it?
< matid> rodarvus: Can you open a bug in Debian via Malone?
< sfllaw> From: Simon Law <sfllaw@ubuntu.com>
< sfllaw> To: submit@bugs.debian.org
< sfllaw> Subject: Unhelpful error message: "Error opening pic_db.dat for read"
< sfllaw> Package: pixelize
< sfllaw> Version: 0.9.2-2
< sfllaw> Severity: minor
< sfllaw> The pixelize(1) manpage doesn't mention that you have to run make_db(1)
< sfllaw> before pixelize becomes useful.  Please edit it such that it does.
< sfllaw> This bug was initially reported in Ubuntu:
< sfllaw>     https://launchpad.net/distros/ubuntu/+source/pixelize/+bug/55188
< sfllaw> Thanks!
< sfllaw> rodarvus: I don't think so...
< rodarvus> yes (in theory) click on "+ Distribution"
< rodarvus> only existing bugs, then?
< sfllaw> Only existing bugs.
< eigenlambda> it isn't linked to the debian bug yet
< sfllaw> I'm waiting for a bug number to pop up.
< sfllaw> Debian's BTS will send me an e-mail.
< eigenlambda> oh
< matid> So is it not enough to click +Distribution, select Debian GNU/Linux, select the source package and click 'Continue' I guess
< sfllaw> But anyway, when I get it, I will +Distribution
< sfllaw> Select Debian as the Distribution.
< sfllaw> Type in pixelize as the source package name.
< sfllaw> Then I will Link to a bug in another bug tracker.
 * eigenlambda used to use debian, but only ever filed one bug (with a patch) and never figured out the bug tracker
< sfllaw> Choose Debian there.
< matid> Ok, so that's the order.
< sfllaw> And type in the bug number below.
< matid> Malone can't create new bugs in any other bug tracking tools? It can only link to existing bugs?
< sfllaw> matid: That's right.
< sfllaw> We felt that it would annoy other people if Malone auto-filed bugs.
< eigenlambda> ya, i don't think other people would like it if we automagically created bugs for them
< matid> That's true.
< sfllaw> OK.  Now I'm going to send an e-mail to the upstream author.
< eigenlambda> especially because bugs we end up filing might very well be dupes of bugs in their bug trackers
< lionelp> sfllaw: so you need to run a Debian to report a Debian bug ? (or to know all the field sent by reporbug tool)
< matid> You can do it via email I think. It described here: http://www.debian.org/Bugs/Reporting
< matid> s/It/It\s
< eigenlambda> ya, that's how i had to file a debian bug
< eigenlambda> 'cause my school silently blocked port 25
< eigenlambda> and the cut me off saying i had a virus
< sfllaw> From: Simon Law <sfllaw@ubuntu.com>
< sfllaw> To: Paul Wilkins <pwilkins@lashwhip.com>
< sfllaw> Subject: Pixelize: Ubuntu bug
< sfllaw> Hi Paul,
< sfllaw> One of Ubuntu's users of pixelize got confused by your error message
< sfllaw> that reads: "Error opening pic_db.dat for read".  Here is a link to our
< sfllaw> bug tracker:
< sfllaw>     https://launchpad.net/distros/ubuntu/+source/pixelize/+bug/55188
< lionelp> matid: right, thanks !
< sfllaw> eigenlambda: Oh man, that's really lame.
< sfllaw> I suggest that you might change this to instruct the user to run
< sfllaw> make_db, when appropriate.  Maybe something like: "Can't find
< sfllaw> pic_db.dat.  Have you run make_db?"
< sfllaw> Thanks!
< sfllaw> OK.  Let's find a bug that's already been triaged and look at it.
< sfllaw> https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/49088
< sfllaw> Here's a fun one:
< sfllaw> Ubiquity.
< sfllaw> Here, William was the first to respond.
< sfllaw> Nice and polite, I might add.
< sfllaw> That's good, because https://wiki.ubuntu.com/DebuggingUbiquity asks that people attach the right files.
< sfllaw> And William also subscribed to the bug, so he can get the original reporter's response.
< eigenlambda> and set it to 'needs info'?
< sfllaw> Yup.
< sfllaw> Needs Info is basically where triaging happens
< sfllaw> Sadly, it looks like this bug can't go any further.
< sfllaw> chris has not kept the log files around.
< sfllaw> And he's worked around the problem.
< sfllaw> But, lots of other people seem to have a similar problem, where ubiquity eats their system.
< gnomefreak> sfllaw: thats a bad thing?
< sfllaw> When it eats their system.
< sfllaw> Generally, installers shouldn't do that.
< sfllaw> :)
< gnomefreak> sfllaw: no people confirming without the all the logs (we cant tell if everyones is the same issue)
< sfllaw> Yeah.  Everyone seems to have different issues.
< sfllaw> So what should we do here?
< gnomefreak> william did a great job with the triaging but i would ask everyone to file seperately
< eigenlambda> ya
< sfllaw> Yup.
< gnomefreak> sorry my opinion on that :(
< bx> if there a way to divide the bug into different bugs without asking users to refile?
< sfllaw> You can do it yourself.
< sfllaw> By hand.
< sfllaw> :(
< LaserJock> :-)
< gnomefreak> and subscribe the person that should have filed?
< sfllaw> Yup.
< sfllaw> So I'm changing the status of this bug to Rejected and leaving a nice note for chris.
< bx> so we would actually file new bugs to divide this one up?
< gnomefreak> can make for a log day :)
< sfllaw> And then I'm going to split up the bugs that Matt Blissett and romu filed.
< sfllaw> Oh.  And Alwar.
< sfllaw> Note that I'm subscribing to this bug, in case chris wants to reopen it.
< eoghan> Can 'just anyone' reject bugs?
< sfllaw> Basically yes.
< welshbyte> just anyone can reopen them too so it isn't a problem
< sfllaw> Yup.
< sfllaw> It's quite reversible.
< eoghan> Cool
< bx> as long as people scan through all of the rejected bugs
< sfllaw> I just filed https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/55201
< sfllaw> And set the status, importance, etc.
< sfllaw> The Description, I pulled from bug 49088.
< sfllaw> Notice how if you type "bug #####" it automatically becomes a link?
< sfllaw> And I subscribed Alwar.
< eigenlambda> nope
< eigenlambda> thats nice
< doluu> will this chat logged and published on some web pages?
< eoghan> doluu: I'll mail it to you after if you want
< ranf> http://netz.smurf.noris.de/log
< welshbyte> should go on the wiki
< eoghan> Or that (:
< neverendingo> IMO it will be published on the wiki
< doluu> I have to leave, sure, please do me a favor
< doluu> which wiki?
< eigenlambda> it's fairly obvious what's wrong in bug 5270, but the maintainer is nowhere
< sfllaw> doluu: wiki.ubuntu.com.
< neverendingo> https://wiki.ubuntu.com/MOTU/School
< doluu> :D
< neverendingo> i am too slow...
< doluu> bye all, it was very nice to be there
< neverendingo> bye
< sfllaw> doluu: Thanks for coming.
< gnomefreak> sfllaw: shou we correct the reporter? all i did was ask for info that will help me and changed it to needs info
< doluu> i'm from Mongolia :D, now 01:39 AM here
< eoghan> Man, I hate time zones.
< welshbyte> https://launchpad.net/distros/ubuntu/+bug/54329 i'm not sure if this is a joke or an actual problem.. made me laugh anyway
< gnomefreak> sfllaw: example: https://launchpad.net/distros/ubuntu/+bug/55198 i dont see this as security threat as far as i know the only issue is the bandwidth in UK on security repos
< sfllaw> gnomefreak: Well, it's OK to leave it that way.
< gnomefreak> k
< sfllaw> gnomefreak: The security people will take care of it.
< gnomefreak> ah
< sfllaw> It's just an informational flag.
< neverendingo> sfllaw: what about the state of the initial bugreport?
 * gnomefreak wants to see the shape of his list before i tell him the servers are having troubles
< sfllaw> OK.  I've now split off the bugs.
< sfllaw> And Rejected the initial bug.
< sfllaw> Because we can't fix it.
< gnomefreak> what one?
< sfllaw> chris can never provide us with debugging info, unless he breaks his system again.
< sfllaw> Bug 49088
< sfllaw> https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/49088
< gnomefreak> ah
< sfllaw> If you look at the bottom, you'll see my comments.
< sfllaw> welshbyte: OMG.  That's hilarious.
< sfllaw> You can, of course, file it into the right place.
< sfllaw> And make it a minor bug.
< welshbyte> :)
< matid> Is it ok to mark bug 55194 as a duplicate of bug 44518 ?
< welshbyte> sfllaw: um, i have no idea what package that bug should belong to
< sfllaw> welshbyte: I think it should be related to gnome-panel.
< sfllaw> I don't know what source package that's in.
< sfllaw> But you can search for it.
< sfllaw> matid: They look similar, don't they?
< sfllaw> matid: I think that's fine.
< sfllaw> So that's the end of my little tour.
< gnomefreak> yeah
< sfllaw> Please join #ubuntu-bugs and the BugSquad.
< neverendingo> nice, thank you VEERY much!
< bx> thank you!
< AstralJava> Thanks a bunch sfllaw!
< ranf> thanx
< chesty> thank you
< matid> Thanks!
< welshbyte> sfllaw: ooh, i think it might be alacarte that he's using
< lionelp> thanks a lot
< sfllaw> welshbyte: I dont think alacarte is the one throwing that message.
< gnomefreak> welshbyte: gnome-menu (i wiould go with)
< sfllaw> Sounds good.
< welshbyte> ah ok
< welshbyte> so many grey areas in bug triage :)
< sfllaw> It's true.
< neverendingo> maybe a change to "needs info", too?
< sfllaw> As you do it more, you start making better snap decisions.
< sfllaw> No, I don't think so.
< bx> this was very helpful. now i feel like i can get somewhat involved in ubuntu.
< sfllaw> You can easily confirm whether this is true.
< matid> sfllaw: Do I have to leave a comment on the bug after I marked it as duplicate?
< bx> please be sure to post the chat log
< AstralJava> Yes exactly, a good spot at giving back.
< sfllaw> matid: That's best.
< sfllaw> Oh yeah.
< sfllaw> There are pre-written responses.
< sfllaw> In http://wiki.ubuntu.com/CommonResponses
< sfllaw> I think.
< sfllaw> https://wiki.ubuntu.com/Bugs/Responses
< matid> Thanks
< bx> bye
< matid> sfllaw: Should I include a link to the bug? This yellow box on the top might not be enough to notice.
< sfllaw> matid: It should be fine.
< sfllaw> The yellow box is pretty visible to most people.
< matid> Ok ;)
< eigenlambda> sfflaw: thanks
}}}

----
[[CategoryArchive]]