=== yofel_ is now known as yofel
=== EvilJackyAlcine is now known as JackyAlcine
[03:59] <bfreis> Hi. I'd just like to say that I've lost about 8 hours tracking down a bug on Oneiric's x64 cloud image (it's totally broken), then over 1 hour *trying to report it*. After I finally got a link on launchpad, it kept redirecting me to a huge, HUGE wiki page, forcing me to read lots of useless information. I was just looking for a text area to fill with all the details about the bug and how to fix it, and I'm really disgusted. People at #launchpad said th
[03:59] <bfreis> at people from Ubuntu asked for that redirection because Ubuntu was getting a huge amount of bad reports. I'd like you to know that your "solution" to the problem made be very, very disgusted. I'm sure that you are losing lots of good reports because of it.
[04:00] <bfreis> I'd really like to suggest you to make it **EXTREMELLY EASY** to report bugs. It is good for you when people find bugs and solve them, isn't it?
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest24696
[05:21] <micahg> bfreis: so, it's not hard to report a bug for most people, you run ubuntu-bug PKG or ubuntu-bug -w and click a window
[05:21] <micahg> but people were clicking the report a bug button w/out any useful information most of the time, which is what prompted this change
[05:22] <micahg> apport collects a lot of necessary information, so that + a few sentences from the user is usually enough to go on
[05:22] <bfreis> I perfectly understand that.
[05:23] <micahg> and we're happy to help people file bugs here as well (that + bug triage is the purpose of this channel)
[05:24] <bfreis> However, as you can guess I'm not "most people", and the bug I was trying to report (and finally managed to do so) isn't something that should be dealt with through ubuntu-bug.
[05:24] <micahg> I'm not most people either :), also, we understand some bugs can't be reported that way, that's why there's a section on help.ubuntu.com for manual bug filing
[05:25] <bfreis> You mean, this? https://help.ubuntu.com/community/ReportingBugs
[05:25] <bfreis> come on
[05:25] <micahg> yes
[05:25] <bfreis> Do you really think that people read it more that they read the Facebook Terms of Service before clicking "I Agree"?
[05:25] <bfreis> It is HUGE!
[05:26] <micahg> right, but if people aren't going to read it, in most cases, they probably aren't going to write too much info in their bug either, not everyone, but most
[05:26] <bfreis> I'm sure people give up reporting bugs when they are confronted with such a huge page
[05:26] <bfreis> I totally agree with you
[05:27] <bfreis> The problem here is that the current solution (hide a link on a huge ToS-like page) will repel people who wouldn't write good reports as much as people who can write good reports.
[05:28] <bfreis> I don't know you, but I'd really hate to lose one very good report because I tried to filter out bad reports.
[05:31] <micahg> that's a hard one, we're drowning in bugs, so, some people have been working hard to filter out a lot of "noise" in bugs before they're filed, in any event though, do you have a better idea for accomplishing this?
[05:33] <bfreis> The trade off here is very simple: you help less useful people write less useful bug reports and get helpful people who will write good reports pissed of (if they actually manage to do it to the end... one must be persistent!)
[05:33] <bfreis> Well
[05:33] <bfreis> I don't have a solution, but some ideas
[05:33] <bfreis> First of all, make it damn simple to report bugs
[05:34] <bfreis> A google search for ubuntu report bug should give, in the first result, a link to a form. That's what I was expecting when I first started my quest to find the hidden form.
[05:34] <bfreis> Then, as you said, you have tons of "noisy reports".
[05:34] <bfreis> You could analyze those reports, (programatically) compare them with good reports, and find signals which indicate what a good report is
[05:36] <bfreis> You would know better, since I haven't seen many Ubuntu reports, but you could try to use signals like report length, formatting/organization (is there any kind of paragraph delimitation? is there any kind of list?)
[05:37] <bfreis> Other good signal might be the language level.
[05:37] <bfreis> Ideally, it should be easy to implement another signal once anyone has an idea
[05:38] <micahg> well, the problem is, depending on the issue, it could require a lot or a little text
[05:38] <bfreis> And then, you could have some IA (a neural net, for instance) determine the best way to combine the signals (if you have a list of good and bad reports, it is easy to train a neural net)
[05:39] <bfreis> Sure, that's why the signals alone won't mean anything, they should be combined in (probably) complex ways, and that's where some IA would be good.
[05:40] <bfreis> I think it is a very interesting project that could really improve the noise in bug reports, make it easier to find good reports, and, most of all, make it easier to report bugs.
[05:40] <bfreis> For example, another signal would be mentions to IRC discussions.
[05:41] <bfreis> Or else mentions to serverfault. Or another one could be a search on serverfault for some keywords extracted from the text, to try and find if there has been a question asked related to the problem.
[05:42] <bfreis> For instance, before I reported (and solved) the bug, I asked a question on serverfault. Now, I edited the question and added a link from it to the bug report on launchpad. It could be a signal.
[05:43] <bfreis> Other signal: you could try to match the user who reported the bug with a profile on, say, StackOverflow or ServerFault (or any other relevant web sites)
[05:44] <bfreis> Has any of this been tested already, and I'm just repeating things that won't work?
[05:48] <bfreis> You could use the community to help classifying reports as good or bad. Add a link "Do you find this report useful? Yes/No" on every report on launchpad. Save every click, give more weight to that of users who reported more bugs.
[05:48] <micahg> well, we have quite a few other problems, 1. not everyone is a native speaker, so "language level" isn't necessarily a good test, 2. we have people for other venues pointing to bugs with links to forum discussions, while this is nice, this requires someone to process the entire thread for the useful information (which may or may not be a high priority bug in the end)
[05:49] <micahg> bfreis: we have lots of community members help triage (and sometimes fix :)) bugs
[05:50] <bfreis> 1. "language level" could have a meaning broader than "good english". For instance, do they use technical terms? Actually, a better signal might be: if there are no technical terms, it is a bad report (or, it would get a worse score)
[05:51] <bfreis> 2. Up to a depth (and depending on a set of signals that would say if this is relevant), you could apply the same thing recursively if you find links on the reports
[05:52] <bfreis> I don't know, really, I'm just dreaming out loud here. But I really think this could be done and, even without tremendous effort (like, start with simple signals) I think it could really improve the situation
[05:53] <bfreis> The possible outcomes I see are the following:
[05:53] <bfreis> 1) You will not filter enough, so you will get more noise (because you made it easier to report)
[05:54] <bfreis> 2) You will filter too much, and lose some good reports (which wouldn't be too different from what I suppose is happening now: the difficulty to report discourages ppl from reporting)
[05:55] <bfreis> 3) You will simplify the life of people who just want a text area to write a good report, thus will get more good reports, and will be able to filter out bad reports.
[05:55] <bfreis> If what happens is (1), then you tweak the system. If what happens is (2), then, well, it is not worse then the current situation I'd say. If what happens is (3), all is good.
[05:56] <bfreis> I don't know, but I think if I were still at school and looking for a theme for my final thesis, I'd really enjoy something like this.
[05:57] <micahg> we had 3 before, that prompted 2 (if that's indeed the case)
[05:57] <micahg> it's an interesting puzzle
[05:58] <bfreis> It is tremendously interesting!
[05:58] <bfreis> well, I like it :)
[05:59] <Guest24696> Question on "Fix Released" if a bug was filed on an older release, and fixed in a later one, does the bug stil get marked as "Fix Released"?  Does it change that answer depending on whether the fix will ever be backported?
[05:59] <bfreis> It touches IA, natural language processing, I don't know the volume of reports you have, but it might also be a scalability problem
[05:59] <Guest24696> sorry, nickserver didn't take, let me fix that
[05:59] <micahg> bfreis: we have almost 100k open bugs :)
[05:59] <bfreis> well, IA and NLP on 100k open bugs most certainly will pose scalability problems.
[06:00] <micahg> Guest24696: yes, "Fix released" on the default task means fixed in the development release, you can look here for how to get it fixed in a stable release: https://wiki.ubuntu.com/StableReleaseUpdates
[06:00] <Guest24696> and nickserv isn't cooperating...  well this is mfisch
[06:01] <bfreis> It is a pity I don't have enough spare time to create such a system.
[06:01] <Guest24696> micahg: in this case it will never be fixed in stable, it's a manpage typo, but I'd like to mark it fix released.  Thanks.
[06:01] <micahg> Guest24696: unless you've been banned, your nick isn't an issue :)
[06:02] <Guest24696> micahg: thanks for the info
[06:02]  * Guest24696 goes to restart bip
[06:03] <bfreis> micahg, do you know about how many bug reports you get daily?
[06:04] <micahg> bfreis: no, but some others here might know
[06:04]  * Guest24696 just saw about 22k in the untriaged qyeye
[06:04] <Guest24696> queue even
[06:05] <bfreis> 22k in one day?!
[06:05] <bfreis> (sorry, I don't know what this untriaged queue is...)
[06:05] <Guest24696> bfreis: sorry, missed your "daily" part.  22k untriaged currently, not daily
[06:06] <bfreis> oh
[06:06] <Guest24696> brb
[06:06] <bfreis> Well, I'm just trying to think about the scalability problem of the classification system we were talking about if it would run in "real time"
[06:14] <bfreis> Well, I think that's all I have... I'm currently starting to work on a somewhat similar problem (a search system that should give exactly the document the user is looking for, through the use of many signals related to the documents itself, the user, the recent user behavior, the behavior of it's acquaintances, etc). It is very specific, and not very related to bug reports (it is study material for college students, not even in english -- in portuguese
[06:14] <bfreis> ), but if it could useful somehow, I could share the experiences later on
[06:15] <micahg> I'm not sure, could be
[06:23] <bfreis> It's (very) late, I'm leaving. The idea is there. I'm not often (actually, quite rarely) on IRC, but if anyone would like to discuss it further, you can reach me on my email address (this nickname at gmail dot com). Again, this subject really interests me, but I don't have much spare time.
[06:23] <bfreis> See you!
[06:24] <micahg> bfreis: thanks, and sorry for your bad experience, hopefully you'll have better ones in the future
=== yofel_ is now known as yofel
[16:57] <yofel> jibel: how is bug 896817 a dup of 896451? Sure, I'm getting that bug too obviously (which is in fact a dup of bug 893826 I believe) - but my problem is that dpkg has no way to let me install the package anyway, whether it's a good idea or not
[16:57] <ubot4> Launchpad bug 896817 in dpkg (Ubuntu) "[precise] dpkg can't force installation of multiarch packages with different contents (dup-of: 896451)" [Undecided,New] https://launchpad.net/bugs/896817
[16:57] <ubot4> Launchpad bug 896451 in qt4-x11 (Ubuntu Precise) (and 1 other project) "package libqtgui4 4:4.7.4-1ubuntu4 failed to install/upgrade: './usr/share/doc/libqtgui4/LGPL_EXCEPTION.txt' is different from the same file on the system (affects: 6) (dups: 9) (heat: 72)" [High,Confirmed] https://launchpad.net/bugs/896451
[16:57] <ubot4> Launchpad bug 893826 in qt4-x11 (Ubuntu) (and 1 other project) "symlinked docs are different between architectures, depending on dpkg-deb package order (affects: 11) (dups: 6) (heat: 86)" [High,Confirmed] https://launchpad.net/bugs/893826
[17:02] <penguin42> yofel: I agree it's probably not a dupe - although I could imagine the dpkg might be an invalid/wontfix - I can imagine it might be a pain to let it do that
[17:03] <yofel> well, it's not really much differen than using --force-architecture --force-overwrite with 2 package from different architectures with conflicting files
[17:03] <yofel> *different
[17:05] <penguin42> yeh, I guess if you can force-overwrite then it should allow it
[18:17] <jibel> yofel, this is a known problem with gzip that needs to be worked around in the package until gzip if fixed
[18:17] <jibel> *is fixed
[18:17] <yofel> well.. I agree, but that's not what I complain about in the bug
[18:18] <jibel> or maybe not, let me look at it again.
[18:18] <yofel> my problem is that dpkg gives me no way to tell it to install the package anyway, while it would let me overwrite a package with the same architecture without complaining
[18:20] <jibel> yofel, agree, I unduplicated your bug, sorry for the noise.
[18:20] <yofel> np, happen :)
[18:20] <yofel> *happens
[18:38] <micahg> jibel: yofel: are you aware of any upgrade issues from oneiric to precise with akonadi-backend-mysql?
[18:40] <jibel> micahg, I'm not aware of any bug report, but I've seen that it is removed on upgrade due to the transition to mysql-5.5
[18:41] <yofel> I did notice it was being replaced by akonadi-backend-sqlite when I looked in muon today.
[18:41] <yofel> and I would blame the same thing jibel said
[18:41] <micahg> oops, I meant akonadi-backend-sqlite
[18:42] <micahg> I've got an error about pm.DoINstall()
[18:43]  * micahg will file a bug in a bit if no one has seen it
[18:43] <jibel> no issue about akonadi-backend-sqlite I'm aware of.
[18:45] <yofel> can't test until my deps are back in order, and my ppa upload of qt will take a bit more to build
[19:31] <penguin42> oh ffs - spam on bugs
[19:33]  * penguin42 assumes this is something walking the address book of a user; see last two entries on bug 874723 - is there a way to clan it up?
[19:33] <ubot4> Launchpad bug 874723 in upstart (Ubuntu) "Ubuntu 11.10 startup and shutdown times (affects: 8) (heat: 40)" [Undecided,Confirmed] https://launchpad.net/bugs/874723
[19:33] <Ampelbein> penguin42: ask a question on https://answers.launchpad.net/launchpad
[19:33] <penguin42> ok
[19:34] <Ampelbein> penguin42: The admins will remove the spam and take necessary actions.
[19:35] <penguin42> Ampelbein: If we accept bug comments via mail I guess it's very difficult to avoid.
[19:36] <Ampelbein> penguin42: Yeah, and the more restrictive the filters get the more likely the chance for false-positives.
[19:36] <penguin42> nod
[19:37]  * penguin42 would probably be happy to have default-off for mail responses from his address
[19:38] <Ampelbein> Me too, for unsigned mails.
=== micahg_ is now known as micahg
=== EvilJackyAlcine is now known as JackyAlcine
[23:05] <batouzo> I seem to find a kernel bug
[23:07] <batouzo> in some conditions (I guess when I have 2 sshfs userspace FUSE filesystems mounted) then at random system does not see any files, e.g. claim no binaries exist - e.g. /bin/ls File not found . Each few seconds it toggles between not working (running any program always fails with file not found) and working state. Ubuntu 10.10