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 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