=== JanC_ is now known as JanC === ArgSim is now known as GreySim [09:09] klattimer: ok see if you can assign the ibus bug to "canonical desktop team" [09:09] it should [09:09] My date-time indicator says it's Saturday still... [09:10] I'm assuming that it would be a really obvious link [09:11] I can't see it at all :/ [09:11] klattimer: there should be a yellow ! next to your name in the assignee column [09:11] at the top of the bug [09:12] yeah [09:12] I see that [09:12] ... not so obvious [09:12] welcome to launchpad! [09:13] it says, select a team of which you're a member of [09:13] with a search box [09:13] "canonical desktop team" in there [09:13] if I search canonical desktop team, nothing comes up [09:13] sigh, same problem I have [09:13] :( [09:13] ok fixed [09:14] so basically after you do each one this is to say "ok ken your turn to put it in the distro" [09:14] k [09:15] ok while those are out of the way, the dx team is having a call right now and will find what bugs to give you [09:15] klattimer: are you familiar with how merges and merge proposals work in launchpad? [09:16] nope [09:16] ok [09:16] https://help.launchpad.net/Code/Review [09:20] klattimer: you can snag the code like so [09:20] bzr branch lp:notify-osd [09:20] and just familiarize yourself with it while I hunt down some workflow docs for you [09:21] k [09:21] well I've used bzr a few times [09:21] so that's all good [09:21] merge requests not sure of so familiarising myself [09:22] https://help.launchpad.net/Code [09:22] that's the start [09:22] it will be easier to do it that way because the dx team works all in launchpad, so they'll be able to review your changes and commit directory to the upstream project [09:28] klattimer: examples: https://code.edge.launchpad.net/notify-osd [09:37] klattimer: unless assigned otherwise here's the buglist https://bugs.edge.launchpad.net/notify-osd/+bugs [09:37] hi njpatel [09:37] jcastro, hey dude [09:38] njpatel: klattimer is reading up on bzr, lp, and notify-osd [09:38] he's basically here to polish it off [09:38] ah nice, hey klattimer [09:38] njpatel: but he needs bugs assigned to him [09:39] Right, I think davidbarth mentioned it this morning [09:39] njpatel: also I'm asking him to read up on merge proposals, etc. [09:39] if he's going to be doing all this dx work then he might as well do it the way you guys do it [09:39] jcastro, awesome [09:39] What, badly? ;) [09:40] heh [09:41] Cool, I'm awaiting a call from david to do some triaging anyway, so I'll make sure to do go through the notify-osd ones too [09:41] jcastro, regarding n-osd... you can point klattimer towards me, should any technical questions arise [09:41] hey ho MacSlow [09:41] :) [09:41] klattimer, small is the world :) [09:41] also, mpt pointed to this: https://wiki.ubuntu.com/NotifyOSD#duration [09:42] and these: https://wiki.ubuntu.com/NotifyOSD#position [09:42] do you guys know if there are bugs open for these features? [09:42] and can we confirm which parts of those are implemented? [09:42] jcastro, yup... but I don't know htem by heart (by number) :) [09:42] MacSlow: as long as you know how to assign them to him. :D [09:42] jcastro, :) [09:44] klattimer, jcastro: https://wiki.ubuntu.com/NotifyOSD#position regarding that position... this gconf-key selecting the position-option is not implemented [09:45] klattimer, jcastro: https://wiki.ubuntu.com/NotifyOSD#duration is very tricky/involved... to get it all done [09:46] is the position gconf key as important as the duration ones? [09:46] jcastro, I'd say (and I think mpt would so too) that timing is more important [09:47] jcastro, klattimer: but that I'd check with mpt first before proceeding... just to be sure [09:47] jcastro, klattimer: the whole gconf-position option is certainly easier to implement [09:49] yeah but it's not really user visible [09:49] * jcastro thinks that gconfable options are probably not a good use of resources [09:53] jcastro, the general problem with gconf-options is getting an equal amount of testing for each code-path behind each option and get any potential side-effects covered testing-wise [09:53] hm... does the above sentence make sense to you? :) [09:53] it does [09:53] which is why I think bugfixing and duration makes more sense [09:54] that's my view too [09:59] until there's a UI to configure notifications, adding gconf keys ends up being in the hands of the distribution... of which I'm only aware of one shipping notify-osd for notifications (unless something's changed) so unless ubuntu is going to vary between spins then there really is little point doing a gconf key for position [10:05] klattimer: hi, yeah; i'm doing tons of bug reshuffling and milestoning right now [10:06] davidbarth: cool [10:06] klattimer: there are couple of mem leaks in n-osd first, then some patches waiting to be reviewed and integrated, and then some multi-monitor issues (if not fixed by the former) to merge in [10:07] klattimer: and when you get bored, a request to try and improve the test suite to support unattended tests [10:07] k [10:07] we have some xvfb-based framework in dbusmenu, and i'd love to see if you have ideas to use that i n-osd as well [10:08] klattimer: once i've assigned the bugs, can you take a look and give me some estimates [10:08] k [10:08] the goal being to do a fair but reasonable investment in doing the necessary cleanups [10:09] but not block you for too long on that, because there are other app. indicators bugs that should be fixable once the design is refined (keyboard in particular) [10:12] davidbarth: he's just finished ibus, do you have any opther app indicator bugs in mind? [10:19] jcastro: I've asked before, but hplip works now? [10:19] If that has problems still he could take a look at that. [10:21] sense: we decided that it's best to wait for upstream Qt to implement KSNI [10:21] ok [10:33] jcastro: the keyboard one, but that'll require that some validation from mpt; i think we came up with a good approach last week, but i'd prefer him to finish commenting on that in the bug reports he's on [11:43] davidbarth: any word on those bugs? [11:44] I'm going to head out to lunch in a bit and would like some new stuff to get my teeth into this afternoon === MacSlow is now known as MacSlow|lunch [13:21] mpt about? === MacSlow|lunch is now known as MacSlow [14:08] klattimer: back on n-osd bugs, so can you look at all the high & medium prio bugs in https://bugs.launchpad.net/notify-osd/+bugs, except #428509 and give me a ballpark time estimate? [14:08] I'll take a look through them [14:08] klattimer, jcastro: then i think it makes sense to invest ~2-3 days to start with [14:08] k === daker_ is now known as daker [14:33] davidbarth: a rough guess would be something like 6 days for high + medium on there [14:34] as long as I don't hit any major trouble along the way [14:34] lets say probably 9 is a safe estimate [14:37] klattimer: ok, with automating testing being harder or easier than leaks? [14:39] easier, there seems to be better pointers in total, but memory leaks are ok too === daker_ is now known as daker [14:39] pointers to resources I mean :) [14:43] Morning. [14:44] afternoon === seif_ is now known as seif_please_plea === seif_please_plea is now known as seif_please [15:58] jcastro around? [15:59] bratsche: yep [16:00] jcastro: Oh hey dude.. was wondering if you have any priority bugs in the queue that ayan could work on? [16:00] ayan? [16:01] He's finished up the bugs assigned to him and was wondering if I know of anything else he can hack on that's desktop related. [16:01] give me a minute [16:01] any specific area? [16:02] or just ayatana bugs in area [16:02] jcastro: I figure just any ayatana bugs that you've been watching. If not it's no big deal, I just didn't have any specific bugs I could think of so I figured I'd ask you. [16:02] on the phone, give me 2 minutes. [16:03] Sure, no worries. [16:06] bratsche: any of these would be great: https://wiki.ubuntu.com/NotificationAreaTransition/CompatibilityFixes [16:07] ayan ^ [16:08] that's like a ton of stuff in the archive [16:08] so best thing to do is do a cost/benefit analysis of how popular something might be [16:08] ie. start porting apps that are most used. [16:09] you'll need to cross reference http://popcon.ubuntu.com/ ftw [16:10] the bugs themselves are tagged with "trayaway" in lp: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=trayaway [16:10] (or should be tagged with that) [16:14] also, any papercut: https://edge.launchpad.net/hundredpapercuts/maverick [16:14] ayan: is that enough? ;) [16:15] vish: feel free to jump in here, heh [16:15] yay! [16:17] sense: you too! === kenvandine_ is now known as kenvandine [16:24] ayan: what happened to Bug #8949 ? any luck with that one? [16:24] Launchpad bug 8949 in gtk+2.0 (Ubuntu) "Opening a deleted 'recent document' results in a new file. (affected: 6, heat: 95)" [Low,In progress] https://launchpad.net/bugs/8949 [16:25] jcastro: Most certainly not right now! :P === seif_please is now known as seif [19:34] hi, I'm new here. I missed the section or documentation that says where to get the code from to Fix bugs. Does anyone here know the link that references how to do so? [19:37] kelelsai: https://wiki.ubuntu.com/Bugs/HowToFix ? [19:39] thanks [20:29] hi, can anyone familiar with the unity design tell me, where that dark line at the bottom of the panel comes from? [20:29] http://img.xrmb2.net/images/792578.png