=== secretlondo is now known as secretlondon === dudus_ is now known as dudus [09:00] how to use most recent nvidia drivers? since the glx-new seem to be crashing [09:00] glx-new _are_ the most recent nvidia drivers. [09:04] RAOF: I use them. regarding my resets in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/228417 [09:04] Launchpad bug 228417 in linux-source-2.6.22 "random lockups, screen off, USB keyboard stops working (numlock etc), sys-rq-b doesnt work. Gigabyte GA-MA78GM-S2H; nvidia 8600 GT" [Undecided,New] [09:05] Oh, those would be Gutsy's nvidia-glx-new. No, they're not the latest version. [09:05] how to get the latest [09:05] the latest should NOT have this SMP nvidia bug? [09:05] No, the latest still have that SMP bug. [09:06] * LimCore bitchslaps nvidia CEO [09:06] they know about this bug right? [09:06] got urls about this bug? [09:06] Yes, they do. [09:06] Uumm... [09:06] It'll be in a bug on linux-restricted-modules-2.6.24 [09:06] Don't have one offhand. [09:08] lol https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24 [09:08] * LimCore lols @ the bugfest [09:10] What can I say? Drivers are hard, and proprietary drivers suck. [09:14] https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/151382 [09:14] Launchpad bug 151382 in linux-restricted-modules-2.6.24 "nvidia with compiz and with dual core freeze" [Medium,New] [11:11] hello [11:12] hi qense [11:54] I'm going to mark bug 216272 as invalid since the problem reported is fixed. But there is another user with another problem having the same effect. It only happens when his networking is set to automatic, has anyone a clua against what package I should ask him to file a new bug describing his problem? [11:54] Launchpad bug 216272 in hal "internal error failed to initialize HAL" [Undecided,Confirmed] https://launchpad.net/bugs/216272 [12:00] qense: I guess hal would be a good place to start [12:00] is HAL also responsible for networking? [12:00] that's new to me :) [12:01] hardware abstraction layer is responsible for lots of things... [12:01] OK, thanks [12:03] i heard networking auto and certain interfaces files can conflict with nm-applet and gnome network settings... [12:04] that could be the cause === qense is now known as qense|lunch [13:11] G'morning pedro === qense|lunch is now known as qense [13:13] pedro_: you marked one of the bugs you marked as duplicate also as invalid. I'm curious why you did this, because if I remember it correctly it's against the bug triaging policy [13:13] qense: which bug? [13:14] Iulian: morning! [13:14] Bug 228630 [13:14] Launchpad bug 228630 in gnome-system-monitor "processname is cut off after - (dup-of: 66790)" [Undecided,Invalid] https://launchpad.net/bugs/228630 [13:14] hello btw :) [13:14] Launchpad bug 66790 in gnome-system-monitor "Can't show very long command line, and to copy it" [Unknown,Confirmed] https://launchpad.net/bugs/66790 [13:15] it doesn't really matter if its a duplicate [13:16] it dissapeared from the https://wiki.ubuntu.com/Bugs/HowToTriage#head-170e00a7154fcfc87f0fc50f65bba9cff7ab27fe page [13:16] but I can recall such a rule [13:17] well, at least you marked is at duplicate. someone else marked a bug invalid and told it was a duplicate, but forgot to mark it duplicate [13:17] there's no rule about that i'm afraid [13:17] ok [13:17] my bad :) I just was curious about that rule [13:17] well sometimes we also mark them as invalid if we cannot find the exact number of the duplicate [13:17] that can be hard to do if you deal with thousand of reports daily [13:18] there are indeed a lot of bugs [13:18] and that's an understatement [13:18] but yeah i'd love to have a better search system :-) [13:18] that allow me to search for functions names on the stacktraces and things like that === sebner_ is now known as sebner === asac_ is now known as asac [13:46] Hello, I am not able to reach the settings for the loginscreen, is that a known bug? [13:50] you need certain permissions to access it [13:50] did you isntall the system by yourself? [13:51] or manage it? [13:51] askand: I manage it, someone over at #ubuntu have the same problem as me [13:52] qense: it shows up after a long time and under that time the harddrive is very busy [13:52] :( [13:52] you can open other applications with gksu before it? (eg 'gksu gnome-system-monitor)'? [13:52] askand: do you get the gksudo password prompt? [13:54] james_w: qense: Yes I got to the password prompt..however when I tried it again now it opened instantly [13:55] qense: james_w: both of us that had the problem was opening the settings for the first time after installation of the system.. [13:55] seems like some kind of indexing is going on? [14:35] askand: sorry, lost my net connection, did you get my last messages? [14:36] james_w: nope dont think so, did you get mine? :) [14:36] seems like some kind of indexing is going on? [14:36] askand: I think I know what this is, give me a minute. [14:36] askand: good guess though. [14:36] james_w: ahaa ok [14:39] I can't find the bug right now, if indeed there is one filed. [14:39] basically running some things under gksudo fires up a trackerd and some other things as root, and for some reason this trackerd is blocking, when normally it is not. [14:40] that means that when it happens you have to wait until it has indexed your disk, as you found. [14:40] james_w: I see, I thought tracker had been disabled in hardy? [14:40] yep [14:40] and it shouldn't run in this case anyway. [14:42] james_w: I see [14:43] askand: nope, sorry, can't find the bug right now, and the people that I know will know if there is one are off today. [14:44] james_w: ok perhaps they will see this later or something, thanks for helping :( [14:44] :)* [14:44] no problem === _neversfelde is now known as neversfelde [15:20] hello [15:21] Laney: bdmurray and thekorn are probably the best people to ask about py-lp-bugs [15:21] hi dashun [15:21] i have upgraded to ubuntu hardy and i get random disk shutdowns, where i can move the mouse for a while, but ultimately need to REISUB [15:21] hi james_w [15:21] james_w: Thanks [15:21] bdmurray, thekorn, or anyone else: Is there an API reference available for py-lp-bugs anywhere? [15:22] ...after REISUB, the disk doesn't start in bios and need to switch off and on to continue... so do i file a bug for this? [15:22] Laney: I don't know if help() from a python interactive session is helpful [15:23] dashun: probably. [15:23] what's REISUB? [15:23] the safer way to reboot. alt print+screen then those letters. limits the amount of file corruption i have been getting with the continual reboots... [15:24] and it's definitely a disk issue, it's not X freezing or anything? [15:24] Laney, we have some wiki pages: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug [15:25] Laney, and https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/API_changes/BugListExample [15:26] for a start, [15:26] thekorn: Aha, thanks. I was looking for how to submit a bug, which seems to be here [15:26] i can hear my disk drive lose power or something (same sounds as hibernating and switching off), and after REISUB reboot, bios doesn't detect the disk... [15:26] Laney, feel free to ping me if you have further questions [15:26] Cheers [15:27] james_w: i can also move mouse and type letters into terminal, commands just don't work (e.g. ls) [15:28] dashun: I would suggest filing a bug on the kernel [15:29] can you tail -f /var/log/syslog and look for anything interesting next time it happens? [15:30] i have checked the logs i know, but couldn't see anything interesting [15:31] i have been following http://ubuntuforums.org/showthread.php?t=765510... [15:32] .. and didn't know whether another bug report with seemingly randomly occuring bugs would be of benefit... [15:32] *randomly occuring freezing* [15:34] that forum thread has about 4 different problems described in it. [15:34] a bug might be helpful, I would think it was your best bet. [15:34] it would help to get as much information as possible though. [15:35] https://wiki.ubuntu.com/KernelTeamBugPolicies might help you [15:38] cheers james_w, i was going to follow that. i just came here to check because in http://www.ubuntu.com/community/ReportProblem it says "When to file a bug - You can repeat the problem", which i can't [15:38] dashun: you can't repeat it at will, but it does keep happening doesn't it? [15:38] my computer could go down right now... [15:38] what kernel version are you running? [15:39] Boo [15:39] % uname -r [15:39] 2.6.24-17-generic [15:42] and yes it does keep happening, about ~15 times in past week, open file corrupted 3 times [15:42] and since upgrade to hardy only [15:45] dashun: do you have the -16 kernel installed on your machine? [15:48] james_w: i did, but the crashing/freezing started, and so when the -17 kernel came, i upgraded, hoping that fixed it [15:49] ok, just wondered if you could narrow down when it started. [15:49] hardy [15:50] which i upgraded to from gutsy [15:50] yeah, unfortunately that's quite a large timeframe for the kernel [15:52] i regularly use aptitude and upgrade the repos so i probably had a recent version of the kernel before upgrading to hardy [15:52] and by recent, i mean end-user repos recent [15:56] i think maybe i was fine on 2.6.22-17-generic [15:56] bdmurray: You around? [16:00] anyway cheers james_w, i will file a bug on kernel ala https://wiki.ubuntu.com/KernelTeamBugPolicies. bye. [16:00] thanks dashun [16:01] hi, is anyone else getting this bug: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/229587 [16:01] Launchpad bug 229587 in nautilus "Unable to copy directory FROM remote location" [Undecided,New] [16:09] ScottK: sure enough [16:10] bdmurray: It seems we're still having trouble with bugsquad people messing with workflow bugs. [16:11] which isn't helped by heno's revert [16:11] I thought we had agreement they weren't supposed to mess with them, but now I hear the documentation about that was all reverted by heno. [16:11] because documentation is, apparently, evil. [16:13] What exactly are looking for from me? I'm not the one who changed the wiki. [16:14] bdmurray: You're in charge of bugsquad. It's your documentation isn't it? [16:14] If someone is making bad edits to the bugsquad docs, I think it's in your area to speak to them about it. [16:15] Currently one person is going through and adding [wishlist] to the title of all the sync requestes. [16:15] It just makes no sense at all, is distracting, and discourages newcomers. [16:16] and increases spam! [16:16] yay, spam! [16:16] Okay [16:17] Additionally, if you've got some way to contact https://edge.launchpad.net/~nglnx and get them to stop, that'd be marvelous too. [16:18] ScottK: i hope that's not a kmos-clone, incidently. [16:20] Okay, just to clarify things I've never heard of this person even though they've joined the bug squad. So saying that a bugsquad person is messing with workflow bugs is a bit presumptuous. [16:21] it's technically correct, though. [16:21] The larger problem is that the documentation saying not to do so was reverted and so we can't even point them at it. [16:22] Hobbsee: If it's a kmos clone, he was making new accounts last year in anticipation of getting booted. [16:22] bdmurray: If the documentation was present, we could just point them at it and ask them to stop. [16:23] ScottK: And what did you do before the documentation was present? Which if I recall correctly you two only wrote last week? [16:23] It's only recently it's started to be a significant problem. [16:23] * ScottK suspects 5-a-day is encouraging more useless bug edits. [16:24] bdmurray: We're trying to make progress and people removing documenation isn't helping. [16:25] ScottK: who is "people"? [16:25] hggdh: heno, in particular. [16:25] hggdh: and anyone else, if they decide to do the same thing. [16:26] ScottK: without trying to argue the validity of your point, it appears in this case that the person in question isn't taking part in 5-a-day, at least not using the tracking part. [16:26] Hobbsee: there is the other side of the coin: we do have a SOP (right or worng, complete or incomplete) for dealing with bugs. It haoppens your current way breaks this [16:26] hggdh: i'm sure it does, but i've yet to see anyone actually propose a valid way of handling them, that fits both teams. [16:27] hggdh: and i asked a few days ago, when the revert was first made. [16:27] james_w: OK. It was more a reference to the perceived general increase in worthless bug churn. [16:27] Hobbsee: I understood this would be discussed on the next meeting [16:27] ScottK: sure, I was just interested so I checked. [16:27] Hobbsee: It was mentioned that we should discuss this at UDS [16:27] bdmurray: what time will it be discussed? [16:28] Hobbsee: I'm not certain but I could look into that for you [16:28] bdmurray: and is it valid to delay it, when people are causing bug churn *now*? [16:28] bdmurray: There's not much to discuss. There's no point in bugsquad fixing workflow bugs. [16:28] bdmurray: All it's going to get them is developers annoyed at them. [16:28] ScottK: again, without discussing the merit: there is no point in you bypassing current bug SOP [16:29] hggdh: I thought we had an agreement last week to change it. [16:29] while i can understand that a more permanent thing should happen at UDS, then discussed with the bugsquad afterwards, it's still something that's happening now, and fundamental changes like that won't happen overnight. [16:29] if you're going to change how the workflow bugs work, to fit in more with bugsquad aims, then the sponsorship teams have to redo their documentation, etc, too. [16:29] there's no way that's really going to happen, with the associated discussion, in under a month. [16:30] Hobbsee: That or I just unsubscribe to all the packages I'm subscribed to and quit worrying about it. [16:30] is it *really* appropriate to do that? [16:30] That'd solve the problem. [16:30] and effectively ignore it in the interim? [16:31] ScottK: no, it wouldn't, because in the case of your bug getting responded to on the list, it stays in the archive indefinetly,when it shouldn't, due to an incorrect closing. [16:31] The bugsquad spam problem is only a problem for me because I'm trying to be invovled in more than the immediate issues that affect me. [16:31] ScottK: You've pointed at one person causing "bug churn". Is there only one within past week? [16:31] bdmurray: I don't know. I only know when people complain about it or when it happens to me. [16:32] I don't see what's so hard about "Developers use bugs to track stuff. Don't change such bugs. You can identify these bugs by ..." [16:32] Well, that's not much to go on. Adittionally if you are getting when nglnx changes a bug you should be able to find their e-mail address in that bug mail. [16:33] Why can't we just agree to that? [16:33] * Hobbsee unsubscribed from ubuntu-archive a while ago, but still saw various bug churn by members of the bugsquad. [16:33] setting a tag, or setting importance. [16:34] ScottK: It increases the barrier to entry for triaging bug reports if people have a specific list of bugs not touch. Additionally, these work flow reports make up the minority of bugs reported in Launchpad so it seems to me that you could be a little bit flexible. [16:34] It's discouraging to new developers trying to learn. [16:34] bdmurray: so, needless spam is encouraged? [16:34] Well, and its discouraging to new triagers to have a list of things not to touch. [16:35] bdmurray: For new people if they don't understand it, they SHOULDN'T touch it. [16:35] this is starting to sound like "let the triagers do whatever they like, just to get them on board" [16:35] Hobbsee: That's not what I said, what I mean is that you guys could be a little bit more forgiving and reasonable. [16:35] is that the intention? [16:35] bdmurray: every time they add something useless like that, it creates yet another bugmail. how is that not needless spam? [16:36] * Hobbsee thought 'forgiving and reasonable' would be not sending them abusive emails, telling them 'DO NOT TOUCH', or something. [16:36] which is what tends to happen when they do something really idiotic, like assigning motu to bugs. [16:36] insta-bug-spam! [16:36] Hobbsee: that lacks any tact and really makes the person sending that e-mail seem like an ass [16:37] bdmurray: that would be the summary of it, of course. [16:37] not the entirety of the mail. [16:39] Clearly what nglnx has done is incorrect. I'd like to see more examples of the types of things that are generating e-mails so I can get an idea of what people are doing exactly. [16:39] Hobbsee: OK. another try, another tack: why are these dev requests kept in new, unassigned for so long? [16:39] hggdh: oftne, they're confirmed. [16:39] hggdh: It's irrelevant. [16:39] hggdh: and because the sponsorship teams don't get assigned, for various reasons, as documented a few days ago. [16:40] hggdh: Many workflow bugs have specific criteria for specific states and the timeline that's resonable is far different than regular bugs. [16:40] ScottK: no it is not. It may be irrelevant for you, but not for bug triagers [16:40] hggdh: Not if they just don't touch them. [16:40] It gets back to "If you don't understand it, don't touch it." [16:40] Which is, I think a good general rule. [16:40] ScottK: you mean lets completely get out of the current API and completely disregard it? [16:41] So the current rule is change it whether or not you understand the bug? [16:41] That's messed upl [16:41] up. [16:41] If that's the case, then yes. [16:41] * Hobbsee notes that the X guys, and the mozilla guys, have special bug methodologies. [16:42] i'm sure that makes it harder for new triagers, because it's not all the same [16:42] so, surely those should go away too? [16:42] Hobbsee: those are for specific packages not *every* package [16:42] [01:35] Well, and its discouraging to new triagers to have a list of things not to touch. [16:43] so, how is a package different from a subscriber, or a set of names? [16:43] although, i see that it's easier to find a list of all those bugs. [16:43] I think it's easier to remember "sync, merge" than "firefox, thunderbird, xorg, xserver, x-x-v-*, ..." [16:44] OTOH, we could also do some things on our side to fix or minimize these cases [16:44] The subscriber portlet is not immediately obvious and its taught as something to look at in the bugsquad's current workflow. [16:44] bdmurray already made a greasemonkey script to find such workflow bugs. It can't be that hard. [16:44] like making request-sync to file Triaged bugs instead of Confirmed [16:44] (when no sponorship is needed) [16:44] or assigning teams to bug reports instead of subscribing [16:44] pochu: how do you handle the case where it's thrown back, as it's wrong? [16:44] I still don't know what's wrong with assigning vs subscribing [16:44] pochu: Generally archive-admins look at a filtered list of archive bugs. They may not see those. [16:44] pochu: i've already said earlier why assigning teams *does not work*. please go back and read it. [16:45] ScottK: I understand, but it's probably not too much work to fix that, and the bugsquad won't probably annoy us for those bugs anymore [16:46] pochu: in particular, they get unassigned, or the assignment switched when someone takes them, which looks the same to the email interface as those bugs which don't have any action on them. [16:46] pochu: so there's then no differentiation, by the bugmail, about what is done, and what isn't. [16:46] pochu: but this need to be discussed with all involved parties instead of just changing the procedures [16:46] Hobbsee: if it was the other day when we discussed it, if you really said it then I didnt understand it, in which case would be nice if you could rephrase (I'm not native speaker) [16:46] geser: ack [16:46] workflow bugs are no new invention [16:47] geser: documenting existing, unwritten procedures != designing new procedures. [16:47] geser: I'm just proposing solutions which could fit to everyone. I understand they may not be good enough though :) [16:48] pochu: try assigning yourself to a bug, then unassigning. note that you get no more bugmail about it. [16:48] pochu: note that you also get no more bugmail if you are still assigned, but no one has done anything about the bug. [16:48] pochu: how do you differentiate between the two? [16:48] That's clearly a Launchpad bug [16:49] pochu: the subscription works, as people don't tend to unsubscribe the archive / sponsorship teams / etc. [16:49] when you are assigned to a bug, and someone unassignes you, you should get that mail, but not future mails [16:49] so you should see you are unassigned (and the comment if any) [16:49] pochu: true, but it's a launchpad bug, there are many, and it's very unlikely to be fixed in a reasonably short timeframe. [16:50] pochu: so, for the 6+ months that it doesn't get fixed, a workaround is probably a good idea. [16:50] pochu: do you know if there is an existing bug report for that? [16:50] Hobbsee: so do you think assigning bugs to teams would be ok if that would was fixed? [16:50] bdmurray: I'm looking into it right now [16:50] pochu: yes, i think so. [16:51] pochu: I think not myself. [16:51] wait, no. [16:51] To me, "Assign" means I have given you work. [16:51] As a volunteer, I don't think anyone gets to do that, but me for me. [16:51] ah, yes, it would solve the problem, as long as it also sent mail about the assignee change, too. [16:52] When you're paying my consulting rate, feel free to assign me stuff. [16:52] Hobbsee: sure, it would show both the assignee change and the comment and the status change... (if any) [16:52] ScottK: well, here they would be teams, not you directly [16:52] and assigning a team isn't really helpful either as still nobody knows who is exactly working on it (or even if someone is working on it at all) [16:53] geser++. [16:53] pochu: Indirectly it's the same. [16:53] geser: it also encourages people to subscribe other teams. like ~ubuntu-dev to any bug that the ubuntu developers should fix. *sigh* [16:53] er, s/subscribe/assign/ [16:53] ScottK: but can I ask you to look into something without paying you? [16:54] pochu: You can ask, but not direct. [16:54] So then I can't subscribe ~u-u-s without asking you first? [16:54] (assuming you're in u-u-s) [16:54] Subscribe is not assign. [16:55] geser: I see. You can still reassign it to you, but I guess that's not ideal [16:55] multiple teams can be subscribed, as can multiple people. [16:55] geser: OTOH you can mark it 'in progress' [16:55] there's no actual commitment to fixing it there, just an "i'm interested in this bug" [16:55] Subscribe gets it on a list that I'll look into if I choose. The semantics are fundamentally different than assign. [16:56] ScottK: but AIUI, subscribing you is like asking you to look at it. YMMV though [16:56] pochu: sure, but asking someone to look at it != demanding that they fix it [16:56] pochu: As an individual, yes. But, for example, I don't get bugmail when someone subscribed UUS. [16:59] I see it this way: If there's a sync bug from a developer, assign it to ~ubuntu-archive, which will proceed the bug and fix it. If it's a MIR, assign the bug to ~ubuntu-mir which will proceed it and in the end either fix or close as won't fix. If it's a sponsorship request, assign to ~u-[mu]-s which will either upload, ask for more work, or invalidate the request. If they ask for more work, they can switch it to Incomplete, or reassign to the one w [16:59] pochu: What advantage does this have over subscribing? [16:59] that may not be a perfect, or even a good workflow, but it looks fine to me and IIUC should fix the problems with the bugsquad [17:00] ScottK: that the bugsquad isn't supposed to touch bugs with an assignee [17:00] "supposed" [17:00] pochu: and it gets assigned back to the person, if it gets thrown back? [17:00] bdmurray: there wasn't a single response at my email to the bugsquad(https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000840.html) about the collection of data per source package about which we talked a while ago [17:00] what should we do? [17:00] Hobbsee: yeah, either that, or set to incomplete, or both. whatever is better [17:01] I think assignment is a lot more visible than subscribers in the current layout of Launchpad. [17:01] Additionally, the subscribers portlet isn't covered at all in any triaging documentation or classes. [17:02] So your solution is we have to update all the workflow processes? [17:03] BTW, doesn't seem to exist such a bugreport about not receiving a mail when being unsubscribed, at least looking at the 'email' tag from malone. I'll make one [17:03] but aren't there a lot less devs than bug triagers? If we had to adapt our workflow and make it more complicated with a lot of exceptions I don't know if we can work as good as we do now [17:03] I think there must be some sort of compromise we can come to help further prevent us from meddling with your bugs. [17:03] pochu: let me know the number please [17:04] qense: wouldn't bet on it, when all the devs are effectively bug triagers themselves. [17:04] ScottK: I understand that's not ideal, but neither of the other solutions are either way. [17:04] by team structure, and by function [17:04] you've got a point Hobssee [17:04] but at lot of people start with helping Ubuntu in the BugSquad [17:05] if everything is very complicated there they might be scared away from the project [17:05] if they make things harder for other people, then they need to learn better. [17:05] which of course doesn't mean that everyone should do exactly as the bugsquad wants [17:06] qense: at some level, your argument there expands to "the bugsquad members should be able to do whatever they feel is appropriate, no matter what they've read, so they don't get scared away" [17:06] I think the solution is don't touch stuff you don't understand. [17:06] qense: is that your intention? [17:06] no [17:06] of course not [17:06] I don't see what that's so hard. [17:06] but if we add x exceptions they mighjt get confused [17:07] and mess bug reports up so other people can't find them back [17:07] * Hobbsee thought that was covered above. [17:08] [01:44] I think it's easier to remember "sync, merge" than "firefox, thunderbird, xorg, xserver, x-x-v-*, ..." [17:08] if the sync, etc, exceptions are confusing, then why allow mozilla and X ones, by your logic? [17:08] they aren't very logic in my eyes [17:09] we should try to work with as less exceptions as possible [17:09] Hello, I have been able to find what causes a bug and know what has to be done to fix it..how can I get that out? [17:09] askand: did you report the bug at LP? [17:09] qense: so go tell the ubuntu mozilla guys to change their workflow? [17:10] IMO if bugsquad people are wandering around setting importance to wishlist on bugs or adding [wishlist] to sync bugs, then there needs to be more emphasis on what they should be usefully doing. [17:10] askand: is this the tracker bug? [17:10] james_w nono completly other bug [17:10] I think we should create one workflow standard [17:10] ScottK: I'd still like to see some more examples of the things we've done wrong. [17:10] ScottK: I agree with that [17:10] which is 'compatible' with every team [17:10] askand: ah, ok, have you explained what the fix is in the bug report? [17:11] bdmurray: OK. I'll tell people to come complain to you about it then. [17:11] ScottK: That'd be fine [17:11] bdmurray: Setting a sync bug to 'wishlist' isn't really wrong. It's just pointless. [17:11] james_w: https://bugs.launchpad.net/ubuntu/+source/gmail-notify/+bug/89936 is the bug and it is solved by changning or removing a line in /usr/share/apps/gmail-notify/langs.xml [17:11] [17:11] Launchpad bug 89936 in gmail-notify "Gmail notifier crashes when new e-mail is found and the user are supposed to be alerted about it" [Medium,Confirmed] [17:11] maybe we should make one mailist/tracker to document all confusions/mistakes/complaints and create with the gathered information one workflow for all teams [17:12] ScottK: I think that is subjective [17:12] bdmurray: It doesn't affect any work that's actually done. [17:13] ScottK: developer work, in terms of triaging it may help to make it clear what needs to be worked on. [17:13] does 'to unassign' exist as a verb? [17:14] askand: great, if you can explain what the problem is in the bug report we can probably work to create a patch for that. [17:14] pochu: yes, I think so. [17:14] james_w: For sync bugs it makes no difference at all. [17:15] ScottK: Then why does have them submitted as wishlist? [17:15] Because they technically are, but the archive-admins process them the same if they are whatever. [17:15] s/does/not/ [17:16] doesn't requestsync do that? [17:16] Okay, but then nobody would think the importance *needs* to be set [17:16] james_w: It does now. It didn't until recently. [17:17] But do you think one workflow would be possible or are the requirements of different teams to different to get something like that done? [17:17] james_w: Ok I have now written what has to be done: https://bugs.launchpad.net/ubuntu/+source/gmail-notify/+bug/89936 [17:17] Launchpad bug 89936 in gmail-notify "Gmail notifier crashes when new e-mail is found and the user are supposed to be alerted about it" [Medium,Confirmed] [17:17] Hobbsee: hmm, isn't this Malone bug the same with reassigning a bug to another package? the contacts for the original package won't receive the mail with the change [17:17] pochu: probably [17:17] qense: Workflow bugs do a lot of things differently to meet the need of that particular workflow. Trying to shove them into the general bugsquad paradigm is unlikely to really work. [17:17] pochu: er, yes, i think so. [17:19] there's a certain contradiction. If a user reports a needpackaging it's treated like a normal bug, but when someone wants package to be imported you've got another workflow, although the required actions are the same [17:19] askand: thanks, I'm looking at it now. [17:19] qense: The required actions are totally different. [17:20] Hobbsee, bdmurray: bug 229628 [17:20] both times there needs to be a new package created [17:20] Launchpad bug 229628 in malone "Unassigning somebody from a bug doesn't notify him about it" [Undecided,New] https://launchpad.net/bugs/229628 [17:20] and uploaded [17:20] Also needs packaging bugs have their own workflow involving REVU too. [17:20] pochu: thanks [17:21] I need to reread all bugsquad documentation I think. It seems like a lot of things have been changed lately [17:21] qense: No. In one case a package needs to be made and approved. In the other the archive-admins need to sync it from Debian. Totally different work. [17:21] are there mails send to the mailist when the bug triaging policy is changed? [17:22] askand: sorry, I don't speak Swedish, is the correction you put in the bug report an appropriate translation for "%(u)d unread message%(s)s"? [17:23] maybe the school stuff replaced some Ubuntu stuff in my head and am I the one that's confused ;) [17:23] james_w: yes it works good too, I made a patch for it now [17:23] qense: The workflow stuff for needs packaging, sync, merge hasn't changed in some time. [17:23] ok [17:23] IMHO the most important question here is: what do the responsible launchpad devs think about workflow bugs? [17:23] thekorn: I think that's got it backwards. LP devs should be supporting distro needs, not the reverse. [17:24] yeah, I think the best solution would be an adaption/extension of launchpad [17:24] Good luck with that. [17:24] What to do in the intervening years? [17:25] yeah, that's important now [17:25] use things like [merge] in front of bug titles like [apport]? [17:25] askand: can you try changing that line to "%(u)d oläst(a) meddelande%(s)s" please? Does that still make sense? [17:25] james_w: http://FastFreeFileHosting.com/file/5825/gmail-patch.html [17:25] that would make those things a lot easier to find for you I suppose [17:26] james_w: No that is the problem.. [17:26] james_w: makes no sense :P [17:26] that's the real issue here: It will take ages to implement necessary features [17:26] I think subscription is a non-obvious way to identify these workflow reports right now. [17:27] askand: paste.ubuntu.com is good for passing patches around, it took me a minute to find the download button on that page. [17:27] thekorn: I meant to add this manually, not implement it in Launchpad [17:27] james_w: but since the word mail is kind of both plural and singular it should work [17:27] james_w: ah sorry thanks for the tip [17:27] askand: ok, I'll take your word for it. [17:27] qense: Then there will be a long list to remember. [17:28] just [workflow] ? [17:28]