[14:14] good morn' [15:33] maco, you around? [15:33] bcurtiswx: yes [15:33] maco, care to assist/help/whatever for a UDW class dealing with bugs, nigelb suggested upstreaming [15:34] not really [15:34] maco, kk [15:34] upstreaming is such a weird topic, because "just put it on upstream's bugtracker too!" is what everybody gets told, and it's not even right [15:35] kernel bug trackers seem to be there just to make users feel good about the fact someone else has the bug too [15:38] care to elaborate.. you think upstreaming has flaws? [15:39] i think there's no way you can have random people just going out and sending bugs every which way and have anything good come of up [15:39] s/up/it/ [15:40] SOME upstreams use bugtrackers. SOME upstreams use mailing lists and have a bugtracker just for appearances that they NEVER EVER read [15:40] SOME upstreams get really damn pissed off if they get distro bugs reported to them [15:41] you can't just be like "oh yeah every bug should be linked to an upstream bugtracker that's not even being read and you haven't personally read the code to make sure it's not one of our patches doing it" [15:42] if you're going to upstream bugs, as an individual you need to know upstream's processes and know how to open up a package and see whether debian or ubuntu has made any changes to the code [15:44] all very valid points [15:45] (i also agree with cjwatson that "everybody just triage!" is a stupid system. triaging requires in-depth knowledge of how the pieces fit together. step one: recompile in debug mode. step two: run from terminal and trace execution to failure point. step three: repeat within gdb...) [15:49] well, on the other hand we'd have no triagers for the system if they all had to have that type of knowledge [15:50] but the few we'd have would actually be useful [15:51] learning to compile isn't that hard [15:51] yes, but we'd never be able to keep up with the incoming bug reports [15:51] as if we do anyway [15:51] the difference in your case would be drastically different though [15:52] all that happens now is bugs get lots of churn and no useful action [15:52] so for a while the reporter feels fuzzy that someone is talking to them [15:52] and then just gets annoyed that the only thing happening is "does it still exist? *incomplete*" [15:52] and finally they stop reporting bugs [15:53] because its not like theyre going to get fixed, they're just going to keep getting either "me too!" comments or "is it fixed yet?" 'triager info requests' [15:53] so, how does it getting little to no attention make that any better? [15:53] at least its not lying about whether anyone's going to do anything about the bug [15:53] and at least bugs aren't constantly disappearing off the radars of the people who can fix them by being marked "incomplete" over and over [15:53] being aware of a problem doesn't imply being aware of a solution [15:59] the only reason they should be going incomplete is when more information is required, so even if it falls off radars its not really doing any good being on them if they don't have the right info to begin with [16:00] except people mark stuff incomplete if they dont answer "yes the thing still exists. of course it does. LOOK AT THE LACK OF PATCHES!!!!" every 6 months [16:00] because triagers who aren't developers don't even know what the hell "enough information" means [16:00] on software i haven't personally patched i dont know what that means [16:01] bugs that have enough information stay perpetually in incomplete state never moving to triaged because the triagers are too clueless to know when to move it to triaged [16:01] that's not useful [16:03] I agree, it would be very beneficial to have triagers who knew whether a problem was a config issue, or for example emapthy crashes, but its webkit issues. How can you win-win though? [16:04] stop pretending triaging is what new people should do [16:04] make the requirements of bug control greater, give bug-squad less permissions? [16:05] how do you get people to a level in bug triage tho? they have to start somewhere [16:05] testing patches requires far less knowledge than triaging does [16:06] yeah, thats more of a textbook-reference type knowledge, but how does that transition to better triage? [16:06] in order for me to get better at packaging, i annoy the hell out of people and they all PROBABLY hate me, but im learning? i don't think it's the best way to do so by any means [16:07] because once you learn how to throw a patch at a package to test it, you'll have learned how the source packages work well enough to at least get the "did ubuntu/debian make any changes to this?" part [16:07] given there are several thousand proposed fixes for existing bugs that are being ignored, i think itd be a hell of a lot more useful to have the masses testing those fixes than going in circles on the other bugs [16:10] have you blogged about this before? [16:12] i dont know [16:12] ive probably blogged about the patch testing stuff [16:12] if i didnt im sure nigel did at least 25 times [16:12] and jono [16:12] because thats the point of the Patch Review team [16:12] and Operation Cleansweep [16:13] to deal with the 2000+ patches that are bitrotting on launchpad and have been for years [16:13] so in your opinion, bug squad is really a poison to the system ? [16:14] i dont think ive ever met anyone who was happy with the job bug squad was doing [16:15] "why do they keep asking me whether its fixed when they havent fixed it themselves?" is the most frequently asked question i get about ubuntu's bug processes [16:15] (generally followed by something about Debian handling it better) [16:16] what is debians system? its a big pet peeve of mine when upstream says fix it yourself, when the main idea of bug reports is making sure its filed because you don't know how to fix it [16:17] but on the fixers side, i know that it doesn't help to beg and beg for things to be fixed [16:20] if debian handles it better, i'd love to know how, so i can see what differences there are [16:26] maco, on a different note: Tamarah's taking a visualization class (OpenGL, C) and this requires her to be active on Linux. She currently owns a laptop that overheats with Ubuntu on it, and her having a laptop would be most beneficial. It wouldn't be doing any of the work, just the ability to web browse and ssh to other machines would be best.. what's her cheapest option? [16:26] http://irclogs.ubuntu.com/2010/10/22/%23ubuntu-devel.html#t15:42 [16:27] she can borrow one of my kubuntu laptops [16:28] i like this one: [16:28] or edit the response on the wiki page to have something like "[Edit this to say what you tried to do to reproduce the problem. Dear reporter: if this sentence is in the message you retrieve, then feel free to ignore this message as the bug triager wasn't paying attention.]" [16:29] i love it when those pop up [16:29] i also love what happened in -bugs just now.. someone replying to ubot [16:30] maco, is there a cheap option purchase-wise? [16:30] i may take you up on your offer, just weighing options [16:31] the system76 starling netbook is $385 [16:32] actually i think the dell netbook is 299 [16:32] zareasons above those i assume [16:35] yes [16:35] $449 [16:41] im reading that log, interesting how bdmurray never jumped in on that [16:43] well lunch break, ttyl. good discussion. [18:44] maco, do you know if there was anything discussed past that log about changing triage permissions/workflow etc..? [18:45] no i dont [18:45] its not the first time ive seen cjwatson or ScottK get upset about this stuff [18:45] actualy... [18:45] there was discussion on a mailing list, probably ubuntu-devel, when bug expiry was re-enabled [18:45] I don't blame them though [18:45] which i think was also what triggered that conversation that time