[00:08] no package bugs are almost under 3100 [00:12] talking of no package bugs, i'm just looking at this one - https://bugs.launchpad.net/ubuntu/+bug/252699 [00:12] Launchpad bug 252699 in ubuntu "Bad samba network shares support" [Undecided,New] [00:13] not entirely sure what to do with it. we know that some applications have yet to be ported to GIO, and the reporter seems unaware that he can still access Samba shares through the gvfs-fuse mount [00:14] i don't know whether there are bug reports tracking individual applications waiting to be ported that i could point him too, or whether to just close this one [00:14] given the quantity of bugs in the report it almost sounds like it should be an idea "Rock solid support of samba" [00:15] should i recommend he opens up an idea on ubuntubrainstorm? [00:16] Yeah, unless there is one specifc bug that report could be used for [00:18] the first four comments are really a non-issue (or certainly will be when the rest of the applications are ported to gio). perhaps the only issue might a discoverability one, where the reporter hasn't worked out that they can access samba shares in non-gio applications [03:13] Gnome 2.24 is the targeted Intrepid version, correct? Meaning Nautilus 2.24 will be the Intrepid version? [03:19] and question 2, unrelated, which package would you file a bug report against for the "About Ubuntu" dialog? [03:25] mrooney: what kind of problem with About Ubuntu? [03:30] LaserJock: okay, it is the same question in qa, so I will go for it here. I was just wonder about bug 252621 [03:30] Launchpad bug 252621 in ubuntu "About Ubuntu doesn't use a theme agnostic icon" [Undecided,New] https://launchpad.net/bugs/252621 [03:30] I don't know enough to know if what he describes is a bug, or if he should just be making his theme differently [03:33] and also what package that would be [03:33] well [03:33] gnome-panel is the package [03:34] but it's really tricky [03:34] a lot of the About Ubuntu stuff is hard-coded [03:35] I think his issue isn't that though, because the icon does change if a theme specifies a different one [03:35] it should change if the distributor logo changes [03:35] it just uses the wrong one if you use a theme which doesn't explicitly specify one, apparently [03:38] well, I'm not sure if it's a bug or not [03:48] I know, that is where I am at too :) [03:52] Anyone know what package the gnome logout dialog is? [03:53] apt-cache search'ing doesn't provide anything useful [03:59] mrooney: possibly gdm? [04:31] Gnome session? [07:48] can someone take a look at https://bugs.launchpad.net/ubuntu/+bug/252817 and offer feedback? I'm not sure what I should do with this [07:48] Launchpad bug 252817 in ubuntu "ctrl doesn't work when used in conjunction with shift click for multiple file selection" [Undecided,New] [07:48] I'd like to update on bug 251338 [07:49] Foxconn has been in conference with me several times today [07:49] the problem is not just Foxconn boards, it's spread to ASUS and MSI as well [07:49] Launchpad bug 251338 in linux "Bad ACPI support on Foxconn G33M/G33M-S motherboards with AMI BIOS" [Unknown,In progress] https://launchpad.net/bugs/251338 [07:49] only if you have an American Megatrends BIOS [07:50] how should I update this bug with that information? [07:51] By pressing the "edit description" link. [07:58] bug 251338 [07:58] Launchpad bug 251338 in linux "Defective AMI BIOS on multiple Foxconn, MSI, and ASUS Intel LGA 775 motherboards breaks ACPI support" [Unknown,In progress] https://launchpad.net/bugs/251338 === mcas_away is now known as mcas [10:05] bug 252861 [10:05] AlmightyCthulhu: Bug 252861 on http://launchpad.net/bugs/252861 is private [10:05] security, sweeeeet [10:09] AlmightyCthulhu: Going to inform us of its content? [10:09] Or just noticing that it is private? [10:09] probably would phrase it as [10:10] "npviewer.bin crashed with SIGSEGV right before my pr0n loaded" [10:10] but then it wouldn't get the attention it deserves [10:11] Odd - I should be able to see crash bugs, but can't see this one. [10:11] I reported with apport [10:11] I just noticed a 10 MB crash file [10:11] and figured go for it [10:11] Ah, I guess it might only end up accessible once it is attacked by a retracer. [10:12] yup, the retracer has to look first, and opens it up whether it suceeds or fails I believe. [10:12] It doesn't normally open it up itself, does it? [10:12] Rather subscribed the appropriate team. [10:12] *subscribes [10:13] looks that way [10:13] actually, I was testing a rick roll [10:13] I have my blog set to link every Ubuntu Code of Conduct link that someone spams it with [10:13] to Together Forever [10:13] or Never Gonna Give You Up [10:14] That's slightly nasty. [10:14] wgrant: yeah, of course, sorry. [10:14] wgrant: I'm sick of seeing them [10:14] my link policy is if I no likey, I turn it into a rick roll [10:14] The CoC is important. [10:15] then you really don't want to see my blog, lmao [10:16] there's nothing technically wrong with Ubuntu [10:16] that thing suffers from rectal cranial inversion IMHO [10:17] then Evolution crashed when I opened my hatemail about the rickroll [10:17] so I posted a bug about that too [10:20] I figured the rickroll is the perfect way to deal with the CoC links, it's overengineered, overused, over the top, corny, and lip synched [10:20] but Flash no wanna worky :P [10:22] really, the CoC is fundamental. it can be over applied and overanalyzed [10:23] but its still important ground rules for participation in a community project like this [10:24] I prefer the one rule approach [10:24] "Don't be a (you know)" [10:24] well [10:24] Rule 2: "Unless it's warranted" [10:25] it's how you know a project has no soul [10:26] you have no idea [10:26] Mozilla even uses the bug system when the price of soda goes up 5 cents in the machine upstairs [10:26] they have a sense of humor [10:26] Debian is a rather abrasive community [10:27] the CoC I think largely stems from trying to produce an alternative, workable community [10:28] sometimes banging your fist is the only way to get things done [10:28] things like assuming bad faith, telling new debian users to RTFM and then justifying the abuse because you spend a long day at work [10:28] it should only be used when all else fails [10:28] so how long have you been using Ubuntu? [10:29] since Warty [10:29] before that it was Red Hat [10:29] neat [10:29] and way before that, Slackware [10:29] I still keep Fedora on most of my boxes [10:30] so, I just find that wehen someone hands me the CoC [10:30] it can be just as offensive as RTFM [10:30] The CoC makes Ubuntu a lot more bearable than Debian. [10:30] well [10:30] if not worse [10:30] telling everyone to call the FTC is so ridiculusly overboard [10:30] and assumes bad faith [10:30] of course it does [10:31] someone did this on purpose [10:31] is using undocumented methods and a special version of DSDT and several other tables [10:31] never attribute to malice blah blah [10:31] and going out of their way to detect Linux [10:31] yeah, you would have to intentionally do this [10:31] just putting _OS in there ain't gonna do it [10:32] they've found a way to make Linux listen to that [10:32] look, if you're wrong, we all look like fools [10:32] and [10:32] even though all reference material says Linux doesn't do that [10:32] so according to documentation, Matthew Garrett is right [10:32] according to what is going on, I am [10:33] if he was here and dealing with this, he would be throwing a fit [10:33] guarantee it [10:33] na [10:33] even if you're right, everyone now has one more reason to think twice before giving out engineering support contact information to the linux community [10:34] look, hitting them on a Friday, very publicly was the only way to do this [10:34] otherwise they would have just outright denied it [10:34] and continued their line [10:35] you may not like what I did, but I had to hit them while they were off balance [10:35] or they never would have admitted fault [10:35] alternatively [10:35] and there would still be 10-20 million bad boards out there [10:35] with no resolution coming [10:35] and more shipping [10:36] they're not at fault, and they bent over backwards to fix a percieved customer service problem [10:36] its not clear yet where the problem is, and that they're now calling AMI is a bad sign [10:36] why is that? [10:36] get the darned thing fixed [10:36] fixed like the US Election [10:37] B-) [10:37] so Foxconn is negligent, AMI are the (poop)heads, and Microsoft told them their stuff looked good [10:37] i just dont know what to say. its abrasive and a long term stupid decision to treat them like enemies [10:38] well, they lied and sold me and 20 million other people defective hardware [10:38] and then tried to say fix the problem buy buying Windows Vista [10:38] *by [10:39] so then document the defect so convincingly that they can't deny it [10:39] they aren't denying it [10:39] they have confirmed it [10:39] and are blaming AMI [10:39] and on MORE models than I accused them of [10:40] another plausible interpretation is that they're calling AMI because their engineers cant find anything wrong with it [10:40] it seems possible that there's a flaw in the kernel that gets exercised by their goofy extra tables [10:42] pwnguin: not what is happening [10:42] Brunning already told me [10:42] definitely the BIOS [10:42] they just can't do anything with it cause it's AMI's code [10:43] and this is out of their agreement [10:43] they said they will get it fixed though [10:43] I don't think they'll have any trouble leaning on AMI [10:44] anyways, i need some sleep [10:45] see, lack of huevos is what is pinning Linux down [10:47] stastically you are wrong [10:47] linux won't exceed 51 percent without women getting involved [10:49] and if it ever comes close, expect behavior like yours to merit tortous interference claims [10:53] meh [10:53] Cthulhu does like incomprehensible evil and horror === ApOgEE- is now known as ApOgEE-- [10:58] has anyone ran into a bug about shutdown on intrepid yet? [10:58] gnome DE === persia_ is now known as persia [11:34] could someone on intrepid please run "ls /var/spool/cron/atjobs -d -l" and tell me what it outputs please? [11:35] james_w: drwxrwx--T 2 daemon daemon 4096 2008-05-03 15:26 /var/spool/cron/atjobs [11:36] thanks, is that a clean install? [11:38] james_w: umm, what exactly do you mean? [11:38] james_w: ah, It's upgraded since hardy I think [11:38] ok, thanks [11:40] Intrepid shutdown or reboot sends you to the login screen [11:40] shutdown -r gives you a screen asking you to restart X [11:40] which takes you to the login screen [11:40] :P [11:41] AlmightyCthulhu: that's bug 250506 [11:41] Launchpad bug 250506 in gnome-session "shutdown restarts to GDM" [High,Confirmed] https://launchpad.net/bugs/250506 === mcas is now known as mcas_away [12:03] bah, I bagged another Code of Conduct spam with Rick Astley [12:03] that guy is awesome [12:06] AlmightyCthulhu: at the very least that is off-topic for this channel, please refrain from talking about Rick Astley here. [12:07] I think Ubuntu should build that into it's typo correction system, can we get a time table? [12:56] I found proof of my accusations [12:56] it's in Chinese though [12:56] I'm waiting on someone to translate the bits that are interesting to English [12:56] * Hobbsee wonders if that's really on topic for this channel [12:57] it's about bugs [12:57] they're using Henlan approach to ACPI, without actually implementing ACPI [12:57] and bending over for Microsoft [12:57] is the gist of this [12:57] then surely you should be talking to them? [12:58] I don't speak Chinese, I will link it later when I have some bullet points [12:58] Is this in any way related to Ubuntu? [12:58] yes, very much [12:58] tens of millions of motherboards that won't work right [12:58] due to this [12:59] but only if you use Linux on them [12:59] then you would do better to contact the manufacturer, to fix their stuff. [12:59] I have and they are, but what this guy says is they're falsely blaming a programmer [12:59] it appears you already have forum threads about this, where you can put your discussions [12:59] so that upper management doesn't catch flak for this [13:00] typical [13:01] I guess no matter where you are, some things don't change [13:02] anyone know if bug 252795 is a dup? [13:02] bug #252795 [13:02] * jpds prods ubottu [13:03] Launchpad bug 252795 in ubuntu "pressing the "Power" button shows a logout dialog" [Undecided,Incomplete] https://launchpad.net/bugs/252795 [13:03] AlmightyCthulhu: this channel is for dealing with bugs, and triaging them only. it's not a soap box, nor is it a place to recruit for an uprising against various manufacturers. [13:03] mrooney: yeah, it is, the other was mentioned earlier [13:03] https://launchpad.net/bugs/250506 [13:03] Launchpad bug 250506 in gnome-session "shutdown restarts to GDM" [High,Confirmed] [13:07] Hobbsee: it doesn't SOUND the same [13:07] mrooney: bah. i misread, sorry [13:08] I notice in his screen shot it says live session user, does that mean a livecd? [13:08] yes [13:08] well, unless he's deliberately named himself Live Session User in the installer, of course. [13:11] mrooney: commented on the bugreport [13:11] Hey, I have a question on milestones. https://wiki.ubuntu.com/RCBugTargetting doesn't really sound sensible/relevant. If I find a bug which I believe should be fixed by Intrepid release, can I set the ubuntu-8.10 milestone for it? [13:11] mrooney: I've the same issue [13:14] afflux: thanks! [13:15] afflux: does it just happen sometimes, or always? [13:15] always [13:16] mrooney: are you on intrepid? [13:16] nope, Hardy [13:16] I wonder if there are any bugsquaders/bugcontrollers that don't actually use Ubuntu as their OS [13:17] mrooney: ah I see. Let me explain: the logout dialog has been completely replaced. The usual "logout" button in the top right corner (or was it at the bottom?) now leads to the logout dialog, as you can see in the screenshot the reporter posted [13:18] mrooney: the shutdown dialog is currently located in the applications menu, and the reporter wants to note that pressing the shutdown button should open the shutdown dialog instead of the logout dialog [13:18] shutdown button in this case means the hardware button ;) [13:19] afflux: So the logout button in the top right is intentional? [13:19] hi Hew, why doesn't that page sound sensible? [13:19] Hew: not sure. I didn't make that change ;) [13:19] afflux: Ok then, it's just something I had noticed :-) [13:20] Hew: yes, maybe it gets changed to shutdown in case enough users complain about it. I for example could use shutdown more than logout since I'm on a single-user machine [13:21] Hew: you can change it manually by just adding the shutdown applet [13:22] james_w: I would have thought milestones and release targeting were two separate things, but rather than setting a simple milestone for a task (which is apparently ignored), the guideline says I need to target it for Intrepid first, and then milestone that. [13:22] afflux: yea, single-user here too, I'm in the same situation [13:23] the old logout/shutdown dialog was a patch, upstream has re-organised so that patch doesn't apply, so we are currently following upstream. [13:23] it will probably change before the release, but it's not known yet whether that will be a change upstream, updating the patch, or switching to another patch. [13:24] I'm fine with that, I'm just wondering whether the user will like it ;) [13:24] ah I see [13:24] hang on, I've messed up my session, got to restart it. [13:33] * mouz notices 5 bugs per day can be pretty much :) [13:35] mouz: :) [13:35] Depends on the bugs :) Some bugs take all day just by themselves. Some are easy enough that one can get 50 done in just a few hours. [13:36] * afflux sometimes collects some duplicate python crasher bugs [13:36] woohoo, 50 bugs by running a script :> [13:37] afflux: Does the apport dup-checker not catch python dupes? [13:38] persia: usually, yes, but it fails for some packages like screenlets [13:39] afflux: Ah. Any idea why? [13:40] persia: where one issue in the daemon backend causes every plugin to produce millions of tracebacks. I'm not sure but it often seems like apport checks for the whole traceback, which usually differs slightly [13:41] afflux: differs how? Near the crash, or near the initialisation? [13:41] initialisation, because different modules are calling the same backend [13:42] (I'm not sure whether this is really the problem for apport here, but I couldn't think of something better ;)) [13:43] afflux: Hmm. I'm not sure that's easily soluable other than by the means you use. Unfortunate though. [13:43] persia: bug 197712 is a good example [13:43] Launchpad bug 197712 in screenlets "ACPIBatteryScreenlet.py crashed with OSError in __create_tempfile()" [Medium,Fix released] https://launchpad.net/bugs/197712 [13:45] err, well. maybe I'm mixing something up now. It does detect some of them, but IIRC most duplicates were set manually. [13:46] afflux: Those don't look like clear duplicates to me (based solely on the traceback). At least those I examined differ on the crashing line itself. [13:47] Mind you, they may have a common solution, as it appears the issue is a typing conflict of some sort between the session creation and the screenlet defintions, but they don't have the same trace. [13:47] In other cases, it may not be the same bug (although it likely often is). [13:48] persia: well, the few I looked at were failing with "OSError: [Errno 17] File exists: '/tmp/screenlets'", sometimes in differend localisations [13:50] afflux: Which is usually due to insecure tmpfile creation, but [13:50] without looking at the code it's hard to determine if the insecure tmpfile creation only happens in one place or many places. [13:51] If it's always in the same place, then it makes sense to have them duplicate. If it's in different places, it is likely different bugs. [13:51] Easy for a human to review and see if it's the same call, but maybe hard to automate. [13:51] yes, could be. [13:52] (and in this case I suspect they are, as you've previously shown care with tracebacks and some understanding of python) [13:53] they all start (not really, since it's called before from a module) in create_session() of /usr/lib/python2.5/site-packages/screenlets/session.py, I think that's enough evidence [13:58] See, that's the part I'm less sure about, as the arguments are different. On the other hand, they all end with line 288 of session.py, which uses unsafe tmpfile creation (which is often a security issue). [13:59] That points to likely being the same crash. [14:00] Because they start differently, it may be that the callbacks for each are different: without code examination, one can't know that TMP_DIR is created in session.py rather than generated by the individual Screenlet. [14:01] indeed, you got a point there. [14:02] afflux: Note that in this case, it appears correct: it's just that the Traceback.txt alone isn't sufficient to confirm the duplicate unless you know the code. [14:03] I think, in this special case (with os.mkdir raising an exception with it's argument mentioned) it would be enough to scan the traceback from down to up and notice that a most part looks similiar and fails with the same message. [14:04] As long as one knows that TMP_DIR is defined in session.py (or some other common location), and not by the screenlet. The first time one does that, one should check the code. The second time, one already knows it's a dup. [14:04] ah yes [14:05] If I remember correctly I recently saw some python code which catches exceptions and shows a more detailed traceback, with function arguments and some local variables. Might this help in such cases? [14:07] Boo [14:11] afflux: That would show the values of the variables, which may help with debugging the actual issue, but it won't show whether the definiton of the variable depends on the module being loaded, which one can only know from code inspection. [14:11] true, okay === mcas_away is now known as mcas === ivoks_ is now known as ivoks === ApOgEE- is now known as apoo === nhandler__ is now known as nhandler [20:55] could somebody take a look at this bug with no package and voice their opinion: https://bugs.launchpad.net/ubuntu/+bug/252535 [20:55] Launchpad bug 252535 in ubuntu "provide a formatted form for launchpad's "needs-packaging" submissions" [Undecided,New] [20:56] That's a launchpad wish list request [20:56] thats what i was going to ask [20:56] thanks [20:56] Also I thought there was a wiki page for that too [20:56] with the standard information to include [20:56] bdmurray: I think you are thinking of this: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [20:57] more https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageRequest but yeah thanks [20:58] so this report is invalid really? unless the wiki page needs to be more discoverable. i've never filed a bug report of this type before, so i don't know [20:58] Well, it really could be a feature of Launchpad [20:59] bdmurray: I wonder how that could be done? [20:59] could i ask you to respond to this one then please? i can't set the wishlist status anyway [21:00] bdmurray: with "needs-packaging" being a tag we'd have to have per-tag filing instructions [21:00] LaserJock: I've no idea but grouping the needs-packaging bugs with the bugs w/o a package is less than ideal so maybe the solution could resolve both of those [21:00] bdmurray: well, when I created that system I was told that was the preferred method [21:01] LaserJock: Its the best current solution but could be better [21:01] originally we were going to try to do it like Debian with a project or fake package [21:01] but LP devs said tags were better [21:01] Right and if that happened and we had per filing bug instructions we'd be golden [21:02] yeah [21:02] but uh, we were told not to do that ;-) [21:03] maybe having per-package/project filing instruction there would be better motivation [21:08] How long ago was that? There are per-project filing instructions so maybe a separate project would work. [21:09] well, that was before per-project filing instructions for sure [21:10] I think a new project might really be a good idea [21:11] There are currently ~1000 needs-packaging bugs that have to be sorted out of the rest of the bugs without a package [21:12] hmm [21:13] what we really need a junk projects [21:13] or packages, not sure which would map better in LP [21:15] alternatively though, I think the number of bugs without a package is a symptom of a problem with LP/bug filing [21:15] Its just that having them clumped in another area ends up being a lot of busy work for people [21:15] we really shouldn't have a lot of bugs without a package associated [21:19] bdmurray: am I right that there are 5k open bugs without a package? [21:20] LaserJock: perhaps, the ones w/o a package and new are about 3100 at the moment [21:20] k [21:21] so can you think of any reasons why a bug shouldn't have a package (other than needs-packaging)? [21:21] This isn't a new problem and isn't an easy one to solve. [21:21] Package names are not easily discoverable for reporters [21:21] I know the history [21:28] i've been doing the bugs without a package as my 5-a-day [21:28] I think a bunch are just kernel/hardware related and people don't know what to do [21:30] but a wrong package seems better than no package [21:31] so perhaps LP should help people find packages better rather than just dumping them in no-where land [21:35] or not let them submit until they find one? [21:36] jcastro: well, that's what I was getting at ;-) [21:37] A fair number of bug reports end up in Firefox, wrongly, by virtue of it's liblaunchpad integration and the mozilla team doesn't necessarily know which package is the right package so I wound't say a wrong package is better than no package [21:40] a few reports also seem to wrongly end up with yelp === mcas is now known as mcas_away [21:51] bdmurray: I do, the mozillateam is better able to figure out what package it should be [21:51] rather than having all these bugs with no package at all [21:52] at least with the no package land it is an easy search query for BugHug days :) [22:01] bdmurray: does your no-package list filter out bugs that have the needs-packaging tag? [22:02] sbeattie: which list? [22:02] sbeattie: also there is not !tag filter in launchpad [22:03] bdmurray: there isn't or is a !tag filter [22:03] ? [22:03] there is no !tag [22:03] ok, I knew there was a long-standing bug about that, but thought maybe it'd finally gotten fixed [22:04] bdmurray: e.g. http://people.ubuntu.com/~brian/reports/no-package-clues.html does that include needs-packaging bugs? [22:05] sbeattie: nope [22:06] I can't think of anything but bug 1 and "needs-packaging" that shouldn't have a package associated [22:06] Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,Confirmed] https://launchpad.net/bugs/1 [22:07] so if we were to use a project for the later and maybe special-case the former, we could require a package to be entered when filing [22:09] I think that's a poor solution though [22:09] why? [22:09] seems like a much better solution that currently to me [22:11] I don't really see how having thousands of bugs that just sitting there is helpful [22:11] As greg-g mentioned it is easy to find these now and as I mentioned sometimes people won't know where to put it when it is wrongly filed so what will happen with the bugs then? [22:12] bdmurray: well, if they're filed against a package somebody will know about them [22:12] But not necessarily the right somebody [22:12] so? [22:13] So they'll just be "sitting" somewhere else which is less discoverable [22:13] somebody who has a decent chance of knowing the right package vs. no package at all seems like a clear winner to me [22:14] well, presumably they'll be sitting "closer" to where they should go [22:14] if the user can't get reasonably close we're unlikely to want them filing the bug via LP [22:15] for instance, somebody filing a bug against anything "linux" for a kernel problem is better than nowhere [22:16] similar for anything FF related [22:17] LaserJock: the only thing is there are many many packages which aren't looked at very often (the smaller ones) and having a bug assigned to that package intead of "no package" seems like a bad situation (ie: I won't go look at $random_small_nonused_package but I will look at "no package" bugs) [22:17] it just seems like not requiring a package is helping people do the wrong thing rather than the right thing (i.e. getting the package right/close) [22:17] of course, that is a part of it [22:17] greg-g: well, then we need to address that [22:18] "bugs with no package assigned" should not in general be more well triaged than bugs in general [22:18] hmm, to many "in general" there ;-) [22:18] if we make an effort to look at the nopackage/new bugs every month during a bughug day, then I think the no package category could be useful [22:18] heh [22:19] but it *shouldn't* be useful is my point [22:19] those triagers should be doing other things [22:19] hmmm [22:19] that's wasted effort to me [22:19] it's like having a status that nobody should ever use [22:20] kinda, except, to be honest, there are some people who that is about the level of triaging ability they have. Now... I don't want that to sound like I want to ensure they have something to do, but, just that they are available and willing. [22:20] heh :) [22:20] why have it there, it's just a sink for things to go instead of where they should be going [22:20] yeah, I see that and agree that it is a "sink" [22:20] Additionally, assigning bugs to package is can be an easy entry point for new triagers [22:21] I don't think that's a very useful argument [22:21] I can create all kinds of silly little things for people to do [22:21] but the fact remains if it's wasted effort it's wasted effort and I'd rather find other useful, but easy, things for them to do [22:22] hmmmmmmmm [22:22] and on top of that if the user can't figure out what package a bug belongs to I'm not really certain that it's a great place for new triagers [22:23] as they are likely to get it wrong as well, and then you have doubly wasted effort [22:23] I think those are great places actually. New triagers are fine with asking the "basics" (logs, steps to reproduce) where the nopackage bugs usually lack [22:24] s/where/which/ [22:24] * greg-g is still on the fence on whether bugs have to be assigned to a package to be filed [22:25] minimally we need package and version of Ubuntu [22:25] at least with no package assigned we have a good place to look for these things [22:25] just to have any useful starting place [22:26] and Launchpad should be helping people with those in some way [22:26] and allowing people to just not give information is counter-productive [22:27] the fewer times we have to go back-n-forth with people the better [22:28] it is the perennial debate over "many bugs with some(many) which are described poorly, with the advantage of possibly getting more actual bugs" vs "fewer bugs but better described with the possibility of missing some issues" [22:28] low barrier vs higher barrier [22:28] higher barrier wins almost every time [22:28] i agree that launchpad could do a better job of package assignment assist [22:28] though it's basically a balance [22:29] improving LP moves the "sweet spot" towards more bugs [22:30] * greg-g has no answers strong opinions at this point [22:31] I'm pretty sure we're not starving for bugs ;-) [22:31] who all can assign package names besides the reporter? [22:31] anybody [22:33] heh [22:33] here's an idea [22:33] mturk [22:34] hehe [22:34] pay 5 cents per bug in the no package assigned queue [22:35] or ... don't let people do that in the first place ;-) [22:35] yes [22:35] then we can start the "move bugs out of yelp" program [22:37] I just don't see the point of letting people do things that not only don't help them ("why isn't my bug being looked at?") but doesn't help us [22:39] because sometimes theres no way a computer can know [22:39]