=== rickspencer31 is now known as rickspencer3-afk === asac_ is now known as asac [07:09] Good morning [08:09] Guten Tag pitti [08:10] hey didrocks [08:12] pitti: I had a quick look at bug #182345 for updating it in hardy. My memory was unfortunately good: the correction is not in only on changeset, there had been some code refactoring. So, do we take the svn version (same version than in jaunty?) or prefer to keep as it is? [08:12] Launchpad bug 182345 in nautilus-actions "nautilus crashed with SIGSEGV in gconf_client_remove_dir()" [High,In progress] https://launchpad.net/bugs/182345 [08:14] didrocks: if it's not easy to produce a small and safe patch, let's leave it for now, I think [08:15] pitti: ok, I put the status in "won't fix" [08:45] morning [08:45] hey robert_ancell, how are you? [08:45] pitti: doing well [08:46] hello robert_ancell pitti [08:46] hi seb128 [08:47] robert_ancell: what are you working on this week? [08:47] I've seen the glade update [08:47] seb128: nothing much, I'm currently looking for things to do. I guess I'll stop procrastinating about compiz and try and shift some of those bugs [08:48] robert_ancell: do you still have the gnome-control-center merge on your list? [08:48] seb128: thanks, I knew there was something I'd said I'd do. I couldn't find it on my GTD done list... [08:49] ;-) [08:49] we have a new GNOME next week [08:50] so this week is good time to do a good push on remaining merges, feel free to pick any on merges.ubuntu.com and help other people to do some [08:50] A lot of the stuff left on MoM I don't know a lot about [08:51] did you fix the gdl update? [08:52] I've not seen it on the sponsoring list again [08:53] I worked on the deps - gnome-python-extras needs modifying and gtranslator is ftbfs currently [08:53] I've updated the gdl bug with details [08:53] what needs to be modified there? [08:54] ok [08:54] will have a look [08:54] I will try to list of some desktop tasks for tomorrow if you want [08:55] i'll do gnome-screensaver and inkscape tomorrow too [08:55] I was looking at how hard it would be to make a GNOME desktop + LP linker as we discussed at UDS [08:55] Where do we get upstream versions from? ftp.gnome.org doesn't seem to have easily parseable info [08:56] good idea those, there is a 2.26 gnome-screensaver in bzr which was ready before jaunty [08:56] we didn't upload though because there is an issue [08:56] if you run 2.24 and upgrade, and lock screen you can't unlock [08:56] it seems it doesn't like the server and frontend running version being in mismatch or something [08:57] not sure how to solve that [08:57] seb128: is that 2.24 only? or will it affect 2.22 (hardy) too (for the next lts upgrade)? [08:57] mvo: I didn't try hardy but I would not be surprised if that would be the case [08:57] seb128: in theory, we could have the postinst send a killall -HUP gnome-screensaver [08:58] seb128: and add a patch to re-exec() itself on SIGHUP [08:58] pitti: that would unlock locked sessions while the user ran away thinking the session was securely locked [08:58] hey seb128 & robert_ancell [08:58] hi didrocks [08:58] seb128: if the protocol broke, I don't see a way to keep the current one running and working, though [08:58] I'm a bit concerned that opening a menu or something during the split second between the stop and start would be easy enough [08:58] that would prevent screen locking [08:59] "physical access"... [08:59] right [08:59] seb128: so we have the choice of permanently locking out yourself or loosing lock at all? [08:59] helo [08:59] good point, if you let physical access to your box while not here you are screwed anyway [08:59] lut didrocks crevette [08:59] pitti: sort of, I've no found a great way to deal with this upgrade yet [09:00] well, admittedly locked screensaver is a high enough barrier to stop random fellows walking by [09:00] salut seb128 didrocks pitti [09:00] hey crevette [09:01] seb128: what was wrong with g-c-c? We seem to be running the latest version [09:01] hey crevette [09:02] robert_ancell: we need to merge on debian [09:02] robert_ancell: ie rebase our changes, lower the delta, etc [09:02] seb128: sure [09:10] wow, are there enough patches on gnome-control-center? [09:11] is it mostly ubuntu specific or should this stuff be going upstream? [09:12] the system-wide stuff (patch 50 and 51 IIRC), I tried to get upstream with little success :/ maybe its time for a second try [09:14] mvo: 50_ubuntu_systemwide_prefs.patch and 50_ubuntu_systemwide_prefs.patch? Do you have upstream bug numbers? [09:14] robert_ancell: upstream is working on getting the touchpad changes in 2.27 [09:15] robert_ancell: the 1nn_screen are ubuntu specific, the 50, 51 95_desktop_effects too [09:15] 96_build_sound_capplet was to be able to not use pulseaudio but we said we would drop that this cycle [09:32] see you later [10:16] seb128: thanks for sponsoring btw :) [10:16] didrocks: you're welcome ;-) [10:16] didrocks: do you still have some merge or update on your todlist? [10:16] so, if we stay in our ubuntu packages, apt can handle this case gracefully, without Provides, right? [10:16] todolist [10:17] seb128: nothing, so the todolist is opened for inputswork :) [10:17] inputs* [10:17] didrocks: as written on the bug Conflicts, Provides, Replaces used all 3 together is a special case and make apt upgrade calculation job easier [10:18] didrocks: gnome-python-desktop is for you though, I though you said you would be doing both, same principle, debian splitted the binaries and that will be useful to clean some libs and not install those by default in karmic [10:18] seb128: oki, reading your answer, I was thinking that it was needed only for external dependency and that apt can handle it for internal packages [10:19] didrocks: sorry if I was not clear, still a bit fighting ubuflu, I was saying that some packages out of ubuntu could be depending on those binaries [10:19] + second argument [10:19] seb128: ok, I will work on it, reading which splitting debian has done [10:19] apt special case the triplet use [10:19] understood :) [10:19] so 2 good reason to add the 1 line ;-) [10:19] indeed :-) [10:19] not really highly required but it doesn't cost a lot either [11:28] seb128: question in https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-default-media-player-choice for you [11:29] * seb128 hates spec writting ;-) [11:29] pitti: thanks [11:29] pitti: "# Having a small video player is useful, totem will still be used for that " [11:30] pitti: first item of the design section [11:30] ah, ok; sorry [11:30] "that" == video playing [11:30] sorry if that's not clear [11:30] should I change the wording? [11:30] thanks, approved [11:31] no, I'm just blind [11:31] danke! [11:39] pitti: oh didnt see you approved the bluetooth spec ;) ... now reapproved ;) [11:40] asac: oh, did you just change something? [11:40] pitti: no. i changed it from "Pending Approval" to "Review" [11:40] ;) [11:40] wasnt sure what the right state was [11:43] asac: either is fine [11:44] we don't have explicit reviewers any more, so I'll look at both [11:44] good [11:45] pitti: rick is approver for desktop-karmic-firefox-3.5 ... want to do that as well? [11:46] asac: okay [11:46] done [11:47] asac: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-browsers you mean? [11:47] remember to approve the "karmic" release goal too. [11:47] pitti: thats the general browser spec. there is a dependency just speccing the firefox 3.5 transition [11:47] pitti: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-firefox-3.5 [11:47] okay [11:49] i guess this spec could deserve a burn down chart on its own ;) [12:01] does anybody know - if I use a GtkLabel in a dialog box, with line wrapping enabled - is there any way of getting the label text to expand to fill the horizontal space of the window, if the window is resized larger? [12:02] that's a known GTK bug [12:02] :( [12:02] thanks seb128 [12:02] you're welcome [12:03] i've created a dialog with 2 GtkLabel's to represent primary and seocndary text - one of them wraps at the edge of the window and the other one doesnt, so it looks really odd ;) [12:03] you never noticed the issue? [12:03] it's quite visible in lot of applications, update-manager for example [12:04] bug #20096 [12:04] Launchpad bug 20096 in gtk "Synaptic Dialogs do not wrap text labels dynamically when windows are resized" [Unknown,Confirmed] https://launchpad.net/bugs/20096 [12:05] tbh, i hadn't paid that much attention before. the only reason i noticed now is because i'm trying to create a dialog [12:05] seb128 - thanks for the link [12:21] seb128, I remember there was a summer of code to solve this bug and also provide more flexible layout [12:22] was it never commited? [12:22] no [12:22] I had to mark a dup of this bug yesterday in GNOME bts [12:22] crevette: so patch ready for upload ;)? [12:23] asac, I didn't had the last reply from hadess [12:23] crevette: in gnome bug? [12:23] I had one 2 minutes after my patch upload, and he saw me some small problem I fixed afterward [12:23] crevette: which bug id was it agfain? [12:23] I can cc you [12:24] crevette: heh. better give me the bug id ;) [12:24] http://bugzilla.gnome.org/show_bug.cgi?id=584857 [12:24] Gnome bug 584857 in general "[patch] support notification deamon without actions capabilities" [Normal,Unconfirmed] [12:24] thanks [12:25] crevette: thats a different null thing. imo it shouldnt be needed, but ok [12:25] crevette: did you make a debdiff with the patch yet? [12:25] asac, ah Okay, I was typing my question about that [12:25] :) [12:25] no, I wanted final comment [12:26] crevette: not needed for ubuntu. lets get the two things addressed and then uploaded [12:26] you're luycky I brought my laptop at work today [12:26] heh cool [12:26] so I can do the debdiff if you want [12:26] crevette: yeah. if you want the upload credits, give me debdiff ;) [12:27] I want credit, off course !!! [12:27] you should credit bratsche_ rather [12:28] gnome session login is ssooo slooww [12:42] asac: upload to the ubuntu bug [12:42] uploaded [12:42] id? [12:42] lp 372395 [12:42] Launchpad bug 372395 in gnome-bluetooth "[karmic] Please merge gnome-bluetooth 2.27.5 from debian" [Wishlist,In progress] https://launchpad.net/bugs/372395 [12:43] gratias [12:43] de nada senior [12:44] crevette_: you didnt update maintainer field ;) [12:45] doing that now === Pici is now known as ZarroBoogs [12:46] oh true, === ZarroBoogs is now known as Pici [12:46] I did that in my version, but was lost .. [12:47] crevette_: also you forgot the bug in changelog ... doing that too ;) [12:47] * crevette_ goes to hide him self [12:48] uploaded [12:51] thanks a lot [12:55] when a bug from a previous version is fixed in the developement version, what is the status of the bug I shoud set "Fix commited" or "Fix released" [12:57] crevette: "fix released" when it's fixed in the development release. You can use one of the standard replies from https://wiki.ubuntu.com/Bugs/Responses#Fixed%20in%20Development%20release%20while%20still%20existing%20in%20a%20previous%20release to advise the reporter on how to proceed. [12:58] thanks Ampelbein [13:30] asac, please note for the bluetooth spec, the versions of bluez and pulseaudio for audio stream is important, I don't no if it worth mentionning it in the spec. [13:31] latest pulseaudio 0.9.15 will only work properly with latest bluez versions, and the APIs are perhaps subject to change [14:00] crevette: right. spec says we should upgrade all pieces to latest [14:00] crevette: so latest bluez i would think as well [14:00] I more "worried" about pulseaudio because there is less release [14:01] You can have a bluez release each 2 weeks [14:01] :) [14:05] seb128: the empathy patch for messaging indicator support is still waiting to be sponsored, should that get uploaded before moving it to main? or just do it after? [14:06] kenvandine: we don't care either way [14:06] * kenvandine would like more people to use it :) [14:06] the more critical piece is the loudmouth fix [14:06] I've not noticed it because it's on the universe list on http://people.ubuntu.com/~dholbach/sponsoring/index.html [14:06] which should really also be fixed in jaunty [14:07] will have a look to this one [14:07] it is pretty important [14:07] anyone with a contact in their list that uses a blackberry is hosed [14:07] debian has already uploaded a fix too [14:07] kenvandine: https://edge.launchpad.net/ubuntu/+source/loudmouth seems to indicate it's already fixed in karmic? [14:07] so i guess we should sync instead [14:08] * kenvandine looks again [14:08] oh [14:08] damn bug mail filtering! [14:08] good [14:08] nevermind [14:08] ;-) [14:08] well... we should look at it for jaunty too [14:09] feel free to work on a SRU for it [14:09] kenvandine: I wonder why telepathy-glib and friends don't need libtelepathy? At least I don't see a MIR bug for it? [14:09] it's not impacting the default client so I don't feel it's high importance for us to work on [14:09] pitti: oh... i missed that [14:09] seb128: true... [14:10] but jaunty users know we are switching, and trying out empathy [14:10] jorge is getting lots of gripes :) [14:10] pitti: i will do that now [14:10] kenvandine: in the future, please use the standard MIR template instead of copy&paste'ing an ancient report [14:10] I though they were recommending to try the 2.27 ppa version? [14:10] not necessarily [14:10] pitti: noted [14:10] would be either to get the loudmounth fixed version in the ppa [14:10] thanks! will review the other bits now [14:11] and that doesn't prevent you to work on the jaunty SRU [14:11] I'm fine sponsoring a debdiff I just don't intend to work on it [14:11] ok [14:11] will do [14:11] so if you do the MIR work that's all good, just ping me for sponsoring [14:12] pitti: mind if i use copy and paste for libtelepathy? lots of the content will be the same :) [14:13] kenvandine: seb128: libtelepathy dep is only to keep ABI compatibility for libmissioncontrol-client [14:13] it is not used at all [14:13] oh [14:13] IMO that's totally stupid because MC ABI never was stable anyway [14:13] kenvandine: the standard MIR template also checks for user-visible strings, debconf, and lots of other bits which are important [14:14] pitti: ok [14:14] kenvandine: seb128: When Empathy will be ported to MC5, libtelepathy will be totally dropped [14:14] kenvandine: note that telepathy-glib doesn't actually need libtelepathy [14:14] hopefully that will happen before 2.28 [14:14] kenvandine: but I guess if telepathy itself is a daemon, that will need it? [14:14] another rewritte? [14:14] pitti: telepathy-mission-control does [14:14] * pitti doesn't understand the telepathy stack yet [14:14] ah [14:14] it is the only thing with a dep on it [14:15] but everything deps on telepathy-mission-control [14:15] :) [14:15] pedro_: ola! [14:15] salut seb128! [14:17] kenvandine: also, please put MIRs into the wiki.ubuntu.com/MainInclusionReport/.. namespace [14:17] ok === bratsche_ is now known as bratsche [14:22] asac: since you have an overview about hal-info/modem prober for NetworkManager and connman/that other thing you referred to, maybe you can add the current status of those to https://wiki.ubuntu.com/Halsectomy ? [14:22] asac: note that e. g. connman using hal is fine, since we don't install it by default [14:23] but this page is used by the #udev folks as well, so it'd be nice to have a comprehensive list [14:24] pitti: sure. will check it out [14:30] kenvandine: robert_ancell saw why my program was segfaulting in literally less than 5 minutes [14:31] Seems he knows pygtk quite well (and the vagaries of threading with pygtk) [14:32] hey rickspencer3 [14:32] hi pitti [14:33] rickspencer3: now we know who to go to :) [14:34] rickspencer3: so what was it? [14:34] kenvandine: exactly [14:34] I made the call to initialize threads after I created a window the used threads, but before gtk_main() [14:34] so I "sort of" initialized the threads [14:35] only I could do such a thing, and then think the problem is in a library I am using [14:36] the good news is that the power triaging feature should be ready in a day or two [14:36] I just need to talk to seb128 to find out exactly how he would want to change the bugs [14:40] pitti: https://wiki.ubuntu.com/MainInclusionReport/LibTelepathy [14:40] rickspencer3: cool [14:41] rickspencer3: I updated the quickly spec. Didn't reread yet for typos but the content should be ok :) [14:42] pitti_telepathy: ping [14:42] hello [14:42] nice [14:43] kenvandine: thanks; can you please create a corresponding mir bug and subscribe ubuntu-mir? [14:43] didrocks: great [14:43] I'll check it out later [14:43] didrocks: did you see someone else asked to join the quickly team? [14:44] pitti: already done [14:44] :) [14:44] ii libtelepathy2 0.3.3-2 Telepathy framework - old GLib library [14:44] pitti: so i guess i have more work to do :) [14:44] rickspencer3: yes, do you ask him to join it? (I prefer people send an email too when they want to join as it gives bzr access) [14:44] kenvandine: hm, the "old" sounds bad somehow [14:44] kenvandine: currently reviewing the packages, indeed :) [14:45] kenvandine: do you know which source ships the telepathy daemon? [14:45] didrocks: I did not, don't know who he is [14:45] pitti: telepathy-mission-control [14:45] kenvandine: in the MIRs you talk about the "telepathy server" [14:45] ah [14:45] rickspencer3: I will send him an email so :) [14:47] kenvandine: in general, I like telepathy; it's like gstreamer for chat :) [14:47] yup [14:47] it has a bright future :) [14:51] re [14:51] asac: did you read my question before? [14:51] I got disconnected apparently but didn't notice [14:51] or rather my IRC disconnected [14:52] anyway let me know if you read the question and,or replied ;-) [14:55] seb128: nope. pleaes repost [14:56] didnt get your question (most likely got eaten on reconnect) [14:56] asac: is installing plugins in /usr/lib/mozilla/plugins correct nowadays? [14:56] asac: totem also do symlinks in /usr/lib/xulrunner-addons/plugins is that required? [14:58] pitti: i would actually be fine not shipping telepathy-idle at all, it is a pretty weak excuse for an irc interface [14:58] seb128: i think we should keep both for now. though in the end mozilla will probably be it [14:58] most irc commands aren't supported [14:58] seb128: it doesnt hurt at least [14:58] asac: ok thanks [14:58] kenvandine: not sure, pidgin wasn't much better, was it? [14:58] seb128: opinions on shipping telepathy-idle? [14:58] pitti: pidgin is far better :) [14:59] no, but I'm not a reference, I don't understand that people use an IM as an IRC client [14:59] and i am not a fan of pidgin for irc [14:59] kenvandine: I didn't have -idle installed, but I did have -haze; I wonder why it doesn't support IRC through libpurple then [14:59] but lot of people there seem to be using pidgin for IRC [14:59] ask rickspencer3 maybe, he's using it for example [14:59] kenvandine, seb128: right, both pidgin and empathy are pretty bad IRC clients :) [14:59] but it's handy to have _some_ IRC connectivity on a live system/on our defautl client [15:00] kenvandine: can it do /join, /msg, /query, and /close? With them you should get pretty far [15:00] pitti: empathy has only /msg and /me [15:00] for the casual "ask the folks in #ubuntu for help" === rickspencer3-afk is now known as rickspencer3 [15:00] Zdra: it opens a new window for /msg? [15:01] Zdra: ok, /close -> close window, /join -> has menu entry, so we could do without them [15:01] pitti: oh, no, it does not have /msg :p [15:01] hm [15:01] * rickspencer3 ears prick [15:01] but it has /say [15:01] ! [15:01] hm, never used that [15:02] it's useless [15:02] I think /me is pretty key [15:02] /command [15:02] but /msg and /query as well [15:02] /say is only useful to prefix a command so it does not interpret it [15:02] kenvandine: I assume that you can use the telepathy GUI for /msg? [15:02] if we want an IRC client let's install xchat-gnome again rather than telepathy-idle [15:03] rickspencer3: let me try [15:03] seb128: i am with you! [15:03] the idea is to have a xchat-gnome-like UI for MUC in empathy [15:03] seb128: kenvandine: I think our default IM client should have basic IM capabilities [15:03] but we need someone with free time to do the job [15:03] rickspencer3: yes [15:03] I'd rather not include both a chat client and an irc client [15:04] kenvandine: does it do tab completion on names? [15:04] rickspencer3, seb128: I considered pidgin enough IRC capable to get to #ubuntu to ask for help (live system) [15:04] I mean nicks? [15:04] pitti: agreed [15:04] if -idle meets that, it's good enough IMHO [15:04] works for me [15:04] pitti: I'd like to be a tad more crisp for the requirements [15:04] geeks who use it all the time won't use it anyway, but they can install xchat/irssi/weechat/whatever themselves [15:04] ie, be able to join a channel and write things there? [15:04] but in general, I agree [15:04] and I wouldn't like to install another IRC client by default [15:05] most people don't need one, and we are tight on space [15:05] seb128: I also think "start a private chat", do "/me", and maybe a couple of other things may be important [15:05] pitti: aside from the space issue, it's confusing to include two [15:05] what purpose do we think the default IRC client serves? [15:05] being able to get IRC support [15:05] we are supposed to be making opinionated choices that makes things simple [15:05] or being able to use IRC in decent ways, including notifications, private chats, etc [15:06] because those are different things imho [15:06] seb128: yes to support [15:06] and I think we should define "decent" as "casual" [15:06] hello again [15:06] hey pitti_telepathy ;-) [15:06] pitti is communicating with us using only his mind [15:07] hm, this doesn't even list the people in the room :-( [15:07] :( [15:07] is there a missing plugin or something? [15:07] /msg is not supported [15:07] but it does do tab completion [15:07] * pitti_telepathy sobs [15:07] pitti_telepathy: but kenvandine says you can msg via the GUI [15:07] /me works [15:07] pitti_telepathy: try /nick [15:07] pitti_telepathy: got my query? [15:08] pitty_telepathy: the missing people are a known (and fixed) bug, I believe [15:08] I reported that recently... [15:08] seb128's /query went through [15:08] mclasen: cool [15:08] but it's not obvious how to start a query from the empathy GUI [15:08] I guess that will "just work" once the people list starts working again [15:09] * pitti_telepathy goes on with MIR processing [15:09] seems good enough for what we need on the default install then assuming that will be fixed before karmic [15:09] seb128++ [15:09] pitti_telepathy: seb128: agreed [15:10] pitti: contact list is fixed in master for IRC [15:10] seb128: you indicated that upstream was responsive, so perhaps we can use it for a while, and provide some targeted feedback [15:10] pitti: seb128++ == seb129? ;) [15:10] pitti: just click in the contact list of your room and a private chat starts ;) [15:10] pochu: lol [15:10] Zdra: rocking [15:10] rickspencer3: Zdra, cassidy are upstream, and yes [15:10] lol [15:10] * rickspencer3 waves [15:10] well, this responsiveness alone makes it more than worth it! [15:10] Zdra: having a release with that fix would be cool... [15:11] new 2.27 scheduled for next week [15:11] I guess that can wait until then [15:11] mclasen: releases are planned: http://live.gnome.org/TwoPointTwentyseven [15:12] ah, the telepathy stack and empathy are officially part of GNOME now? [15:12] empathy -> yes [15:13] telepathy is an external dep [15:13] pitti: since 2.24, yes [15:45] lool: the workspace switcher bug is a duplicate [15:46] seb128: Hmm ok, I searched but didn't see it; is it in another source package? [15:46] lool: it's rather libwnck or compiz if it's somewhere open, could have been closed as lacking information or configuration issues too [15:46] we get one of those bugs every few months since gutsy or something [15:47] I tend to just close those as duplicate recently because I know I read similar description every now and then, I don't have the exact number though [15:48] It kind of makes the workspace switcher unusable in some configs :-) I tried looking into it some months ago, but I didn't understand what was happening in the Gtk+ resize code; I could reproduce it in a window though [15:49] oh, you think it's a gtk issue? [15:49] I was rather expecting a gconf key being set to something else than 1 where it should not [15:49] I don't think so, but rather an issue with the widget handling [15:49] ie the number of workspaces or something [15:49] that's the viewport, workspace mix which leads to such issues apparently [15:49] I think it's purely a config issue [15:50] seb128: I'm pretty sure it's a widget resizing badly, but well not 10% sure; if you try launching a workspace switcher applet from panel-test-applets, can you grow and shrink the window? [15:50] I can only grow it [15:51] well actuall, I can grow and shrink it horizontally but not vertically; that's probably the bug [15:51] hum [15:51] I think mvo told me age ago about a gconf key to reset to fix the issue [15:52] seb128: Ok; perhaps I'm on the wrong track here then [15:52] I really think the common cause for those issues is a grid layout in gconf which has a value different of 1 where it should not [15:52] ie when using compiz you expect workspace = 1 and use viewports [15:52] and in some case ie seems that workspace != 1 and that lead to such bugs [15:59] lool: what is your /apps/compiz/general/screen0/options/number_of_desktops setting? [15:59] seb128: Oh I think I know what it might be now from what you describe: it looks like there are three rows of this 12 viewports setup [15:59] mvo: 1 [15:59] hm, that should be good then [16:00] lool: right === pace_t_zulu_ is now known as pace_t_zulu [16:04] mvo: Did you get my emails? Did I miss anything I said I would send to you but didn't? I have the feeling I forgot something [16:11] lool: its all good, its me being slow [16:14] mvo: haha don't tell that to me; I'm the one who needs 10 days to send you a debdiff ;-) [16:31] mvo, are you ok with being the "technical mentor" for our Season of Usability intern on the AppCenter project? [16:32] mpt: sure [16:32] As far as I can tell, that just means being available to answer technical questions about what is and is not possible design-wise :-) [16:32] thanks [16:33] rickspencer3, can you recommend someone to be the technical mentor for the Users & Groups work? [16:34] I guess ideally someone familiar with the mechanics of user accounts, groups, setting passwords, PolicyKit, that sort of thing [16:46] mpt: this is for summer of usability? [16:46] rickspencer3, Season of Usability, yes [16:47] mpt: robert_ancell I suppose [16:47] ok, I'll ask him [16:47] thanks rickspencer3 [17:01] seb128: would be interesting to get your opinion on bug 376186 [17:01] Launchpad bug 376186 in malone "private bug implicit subscription" [Undecided,New] https://launchpad.net/bugs/376186 [17:02] asac, calc: ^ and your's (you also do a lot of bug triage) [17:02] * asac looks [17:04] pitti: I probably said I would not like to be spammed by those by then but turns out I spend lot of time polling on the list so I would prefer to get email notification [17:05] seb128: ok, let's collect some opinions on the bug then [17:05] ideally being emailed when the bug gets over 3 duplicates would be nice though [17:05] I want to know about frequent crashers, not about every random crash [17:07] pitti: commented. i think we shouldnt subscribe users to get this feature. rather launchpad should send mails to "also notified" automatically if they are in the appropriate group [17:07] asac: yes, that's what Brian proposed [17:07] seb128: bug gravity! :-) [17:07] yeah. so thats also my proposal ;) [17:08] but that would be web-based again [17:08] * pitti does a quick break until the meeting [17:08] * asac too [17:19] desktop team meeting in 11 minutes [17:29] * asac waves [17:29] desktop team meeting! [17:29] hi [17:29] hi :) [17:30] hi [17:30] meeting time [17:30] * rickspencer3 taps gavel on desk [17:30] pitti: ? [17:30] * pitti waves [17:30] did awe make it back in time? [17:31] Riddell: ? [17:31] * awe waves [17:31] tkamppeter: ? [17:31] pitti: shall we begin? [17:31] sure [17:31] https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-06-09 [17:32] first topic: reviews [17:32] I got back all the info - so please schedule a time with me at your earliest possible convenience [17:32] I think Riddell and asac are already on the calendar [17:32] questions? [17:32] rickspencer3: is that performance review? [17:32] * asac checks calendar [17:32] pitti: yes [17:33] sorry [17:33] ACTION: All: schedule a time for performance review [17:33] next is a discussion topic [17:33] rickspencer3 proposes pulling the gimp from the CD [17:34] * kenvandine seconds that [17:34] admittedly I'd shed a tear when we do that [17:34] that might cause issue with scanning, esp if we go to gnome-scan [17:34] here's my thoguhts: [17:34] * It takes up a lot of space that we need for couchdb, etc... [17:34] * F-Spot has key features, like crop and red-eye removal [17:34] * It's a power user tool, users shouldn't stumble into it [17:34] calc: no, i don't think so [17:34] usually scanned images aren't good enough quality when first scanned in... [17:34] but it'd give us 6 MB, plus another 20 when we figure out language-support-* stuff [17:34] calc: perhaps :/ [17:35] to some degree its nice to show "here, ubuntu even has a graphics program installed by default", but otoh i dont think its that useful for normal users [17:35] so we may want to throw out the scan program as well if do go ahead and throw out gimp [17:35] there's a potential issue with gnome-scan? [17:35] hi [17:35] and it's a really "forefront" foss app [17:35] aiui gnome-scan actually more or less works as a plugin to gimp [17:35] I've been pondering about dropping gimp for a while too now [17:35] asac: and pitti: make good points [17:35] gnome-scan has it's own UI [17:35] but [17:35] also a gimp plugin [17:35] pitti: these days there's lots of forefront foss apps... [17:35] shame that we don't have a simple application to sketch or draw something quickly though [17:36] kenvandine: the UI doesn't let you do much of anything though, right? [17:36] calc: assuming normal users will fiddle with gimp [17:36] what is couchdb (sorry if i missed this key app) ? [17:36] lets you scan [17:36] kenvandine: as far as color correction, skew correction, etc? [17:36] but if I were to pick the next app that we kick, it'd be gimp, yes [17:36] calc: none of that [17:36] asac: backend storage for U1 [17:36] it seems to me that f-spot kind of made the GIMP less necessary [17:36] pitti++ [17:36] (or the other way round :-P) [17:36] but if I were to pick the next app that we kick, it'd be gimp, yes [17:36] ^ same from me [17:36] pitti: asac: it's not just for U1 [17:37] generally, a default structured data store is a good thing [17:37] but U1 definitely would be a prime beneficiary [17:38] so, consensus seems to be that if there is still room on the CD, we may as well keep the GIMP? [17:38] rickspencer3: well, the world uses sqlite or bdb, which we already ship [17:38] rickspencer3: personally I wouldn't kick it "just because" [17:38] only if we need the space [17:38] same here [17:38] right agreed. [17:39] what about my point that it is a power user tool that is redundant with f-spot for most users? [17:39] gimp is maybe not the most user friendly application but it has its users and is a well known opensource project [17:39] i had heard someone mention a lot of the disk space usage of gimp is its documentation? i may be confused though [17:39] f-spot is not even close to a photo editor [17:39] well if we consider that image editing is limited to photo [17:39] calc: yes, 20 MB docs vs. 6 MB app [17:39] could gimp be stripped down to a gimp-lite or something, e.g. removing most of the modules, palettes, etc.? [17:39] pitti: but for most users photo editor = crop, rotation, red-eye removal [17:39] pitti: perhaps we can get rid of the docs? lol [17:39] rickspencer3: image != photo though [17:40] do you import your screenshots in fspot? [17:40] seb128: right [17:40] calc: we want to reorganize language-support-* a bit, but not sure whether we want to drop the English documentatino [17:40] I use gimp when I've to resize a screenshot for example [17:40] pitti: ok [17:40] seb128: does not f-spot handle that? [17:40] seb128: ... or for just about anoything else :) [17:40] I don't import my screenshot in f-spot [17:40] this is true [17:40] f-spot handle my photos [17:40] the "import" requirement is onerous [17:40] in fact, gvfs-gphoto makes me not use any f-spot/gthumb etc. at all any more [17:40] sort those by exif tags, etc [17:41] * calc personally doesn't like apps that take over his data like fspot, itunes, etc, but ymmv [17:41] I wish that the gnome image viewer did cropping, red-eye, and annotation (like you could paint on it) [17:41] I use gimp for scanning documents with my flatbed scanner. [17:41] calc: same [17:41] we all know that GIMP is useful [17:41] the question is, does it belong on the CD [17:41] ? [17:41] I'd be inclined to stop shipping the documentatin [17:41] what problem do we try to solve? [17:42] if we have a good replacement for all important use-cases then no. [17:42] and change it so that F1 leads to a browser with the online documentatino [17:42] win CD space? [17:42] it already opens a browser anyway [17:42] pitti: because it is so easy to use, no one needs to docs? [17:42] [17:42] reduce user confusion to have different applications to do a similar job? [17:42] but i would hate to have like 4 apps covering those use-cases. at best we have a single lean app that does all the main use cases [17:42] rickspencer3: no, but not everyone might need them locally installed [17:42] seb128: both points [17:42] if we need CD space I vote for dropping it [17:42] seb128: that seems to be the consensus [17:42] rickspencer3: I would think from a larger view, that we ought to include as many applications (or at least, as most functionality) as possible on the cd. [17:42] not strong will to remoe it [17:42] if we don't I vote for keeping it, it replies to some need we would not fit otherwise [17:43] ^ seems that's the consensus then [17:43] bryce: except we should not have overlapping apps in terms of functionality [17:43] well, I would love to ship a small gtk image editor easy to use with basic features if we had one [17:43] do we have one application matching this definition? [17:43] seb128: lets build an image editor in quickly! [17:43] ;-) [17:43] there's a sweet python image library [17:44] ok, I'll capture the POR as: [17:44] * kenvandine thinks f-spot should have a edit mode without using the library [17:44] 1. keep GIMP unless we need room [17:44] like it has a viewer now [17:44] 2. if we need room, try web documentation only [17:44] kenvandine: can you resize images in f-spot? [17:44] 3. If we still need room, remove from the disk [17:44] +1 [17:44] seb128: not in the viewer, on in the library [17:44] +1 [17:44] +1 [17:44] +1 [17:44] +1 [17:44] +1 [17:45] sweet [17:45] next topic [17:45] Blueprints, specs, burndowns [17:45] I suppose I should turn the mic over to pitti [17:45] * rickspencer3 apologizes for not telling pitti about this topic before now [17:45] https://blueprints.edge.launchpad.net/ubuntu/karmic/+specs?searchtext=desktop-karmic [17:45] so, good job everyone so far [17:46] we have about half of them approved [17:46] please try to get your remaining ones drafted by next meeting [17:46] I usually review them within 4 hours (or on next morning) [17:46] the only outstanding review is for rickspencer3 to do :) [17:47] *cough* [17:47] in terms of burndowns, what is the timeline for getting that system set up? [17:47] any questions about them? [17:47] * rickspencer3 is about 5 seconds in the future [17:47] FYI, I also did a "karmic crack summary" on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [17:48] for burndowns we need to agree on how to define work items [17:48] my proposal is to keep it very simple [17:48] what do we call "burndown" there? [17:48] add something like this to the blueprint's whiteboard: [17:48] Work items: [17:48] do foo:TODO [17:48] do bar:DONE [17:48] do baz:POSTPONED [17:48] --- [17:49] so track on the white board, not in bugs? [17:49] and then have the script parse them [17:49] rickspencer3: well, that's the thing I'm not sure about [17:49] rickspencer3: we could either transform the WIs to bugs and track the status there [17:49] or just use blueprints exclusively [17:49] pitti: i would love to be able to add work items directly to the spec wiki pages and have a bot that assembles a central list [17:49] hmmm [17:49] the latter is easier to set up [17:49] thoughts? [17:49] the former has the advantage that some work items aren't attached to specs [17:50] I would go with "easier to set up" in the meantime [17:50] so the burndown script needs to be able to collect bugs anyway [17:50] I've difficulties to understand what is "burndown" there and what we try to solve [17:50] so basically it would wget, parse, and pipe the info into the script? [17:50] seb128: track number of open/done work items over time [17:50] related to specs? [17:50] seb128: this is a graph that compares work done compared to work left over time [17:50] or any items? [17:50] seb128: remember the workitems list with the chart we tried last cycle? the idea is to improve that [17:50] seb128: to feature work in general, except bugs [17:50] seb128: I think related to specs [17:51] ok thanks [17:51] I think we should start with blueprints only [17:51] and then extend the system to also track bugs [17:51] and if we like it, we might go to change the bug states instead of the whiteboards [17:52] seb128: I'll send you a link to one from last team meeting when I find one [17:52] rickspencer3: WDYT? [17:52] rickspencer3: thanks [17:52] pitti: I think of bugs as different than work items [17:52] rickspencer3: no, not "bugs against nautilus" [17:52] I see [17:52] you are right [17:52] (natch) ;) [17:52] but "bugs against desktop-team-workitems" as a mere means of tracking status and assignee [17:53] pitti: agreed [17:53] I think that you are right that starting with the simpler system is best [17:53] so do i understand correctly that we will have some syntax to highlight work items in the spec wiki pages? [17:53] +1 [17:53] e. g. I have a task for "speed up gnome-panel" which doesn't have a spec [17:53] asac: the white board, I think [17:53] but it takes me about the same time to create a blueprint as it takes me to create a work item bug report [17:54] asac: wiki page is another possibility [17:54] pitti: you don't suggest creating a blueprint to speed up gnome-panel do you? [17:54] the white board seems meant to track status [17:54] but whiteboard tracks the metadata/status already, so it would be appropriate; you disagree? [17:54] i think we can start with whiteboard now [17:54] seb128: *shrug* why not; it doesn't need a wiki page, just a whiteboard, assignee, and short summary [17:54] seb128: like "cache desktop file read, cache translations, speed up xxx", etc. [17:55] yet another system to track, *shrug* [17:55] I would rather use standard launchpad bugs [17:55] well, you need to track your blueprints anyway.. [17:56] I think it makes sense to start with blueprints, and then extend it to bugs, perhaps a hybrid [17:56] pitti: couldn't the script create launchpad bugs automatically? [17:56] awe: sure, it could [17:56] pitti: if possible allow us to assign specific subtasks to someone else like foo@pitti:DONE [17:56] I will follow what other people decide but I've a dislike for blueprints in launchpad ;-) [17:56] with the spec assignee being the default [17:57] those are out of my workflow, not easy to sort of filter, etc, etc [17:57] seb128: +1 [17:57] asac: well, the purpose is just a cumulative status, we don't actually need to track assignees [17:57] hmmm [17:57] for me the main use case is to look at this list and see what tasks i have left [17:57] but bugs are fine for me, just complicate the system somewhat [17:57] pitti: it seems that some people are more bug-centric and some are more blueprint-centric [17:57] (at least from the assignee perspective) [17:57] I think blueprint complicate the system, we work on bugs usually and our workflow and tools are designed for those [17:57] * kenvandine thinks bugs are easier [17:57] for the people who prefer bugs, would you create those bugs manually? [17:58] pitti: sure [17:58] if not, it doesn't make sense to me to define the work items at one place and track them somewhere else [17:58] kenvandine: but that's hard! [17:58] pitti: problem is... we need some umbrella [17:58] i think making bugs mandatory is too heavy [17:58] pitti: is it so hard? [17:58] so a way to group them together [17:58] it isn't hard at all [17:58] how would we file work items as bugs? [17:58] we do it all the time [17:58] s/hard/cumbersome/ [17:58] hmmm [17:59] ArneGoetje: I think just tag them "work-item" or such [17:59] could be time-consuming, yes [17:59] I mean, file against which project? [17:59] i think the hard part is organizing them... it would be nice to have a umbrella (blueprint) linked to all the associated bugs [17:59] whatever needs being worked? [17:59] you need to find the right project, right tags, set assignee, wait for LP, etc. [17:59] changes land to ubuntu so their always concern an ubuntu component [17:59] and link them to blueprints, etc. [17:59] seb128: not true [17:59] apport-retracer-enhancements [18:00] xorg-testing-infrastructure [18:00] hum ok [18:00] help-stripping-in-soyuz [18:00] compiz-bug-workflow [18:00] LP isn't designed to be used for project management, i agree [18:00] kenvandine: seb128: awe: would you be willing to try the blueprint way? [18:00] pitti: 1 example was enough ;-) [18:00] rickspencer3: sure... willing to [18:00] I think it would be much faster to get the burn down chart going [18:00] and then I could start sleeping at night :) [18:00] * kenvandine misses jira :) [18:00] rickspencer3: well, you are the one deciding there so sure, I will try what you say ;-) [18:00] it was great at that stuff [18:00] rickspencer3: sure [18:01] rickspencer3: we want you to sleep! [18:01] seb128: are you granting me dictatorial powers? [18:01] and we want to look at charts pointing downwards to 0! :-) [18:01] because if so, my car needs washing badly, and also my roof ... [18:01] :) [18:01] hehe [18:01] rickspencer3: would you like to be granted dictatorial powers? ;-) [18:01] too much responsibility [18:02] rickspencer3: joke aside I strongly dislike blueprint because they are paperwork usually and don't fit my workflow but I'm fine using those we already do for specs [18:02] lol [18:02] * seb128 really think we need a task tracking system [18:02] let us start with the blueprint method, with the understanding that we will be enhancing the system to accommodate more workflows [18:03] seb128: that's another option entirely [18:03] we could probably hop on some web app designed for this [18:03] let's start with the blueprint use for now, quick and easy [18:03] I do think we need to extend it to use whiteboard AND bugs [18:03] we can figure better ways later [18:03] but that would be *yet another* place to track [18:03] then seb128/awe can switch to bugs if they want [18:03] pitti: agreed [18:03] rickspencer3: no more places to track please :-) [18:03] bug TRACKer :) [18:03] can I say the POR is that we will create a simple whiteboard based system to start [18:03] * kenvandine thinks LP should have task management added :) [18:04] rickspencer3: yup [18:04] and that we will extend it to use bugs if desired? [18:04] personally I kind of like the blueprint system, however I admit I've grown to not rely on it very much. Honestly it provides little benefit that couldn't be replicated easily with bugs + a wiki page [18:04] kenvandine: bugs against a special project do pretty much that [18:04] pitti: mostly yes [18:05] pitti: we need bugs against teams [18:05] pitti: do you have info you need? can we move on, topic-wise? [18:05] maybe with lp going open source, if the blueprint system code is included, it could be improved and better integrated with bugs [18:05] rickspencer3: fine for me [18:05] all? next topic? [18:05] rickspencer3: do you own that? [18:05] next! [18:05] long meeting today :) [18:05] pitti: I think we own it jointly [18:06] lets discuss tomorrow in our call [18:06] yep [18:06] I can do the work if needed [18:06] very related topic: [18:06] Bug hygiene [18:06] * pitti gets the spray [18:06] by this I mean ... I would prefer it if bugs assigned to team members were bugs that were going to be fixed by those team members in the near future [18:07] some of us have lots and lots and lots of bugs assigned [18:07] thoughts? [18:07] feel free to unassign me from everything ;) (assuming you have the script ready for that) [18:08] asac: seriously? [18:08] I tend to assign me bugs I'm going to work on during the current cycle [18:08] well. i dont really use assignments atm for anything but priortizing bug mail. [18:08] https://launchpad.net/people/+me/+assignedbugs should be honest and realistic indeed [18:08] not sure what "near future" you envision though [18:08] one cycle? [18:08] rickspencer3: I generally use assignment more like a bookmark, for bugs I know that are either clear now how to fix, or that I really don't want to lose track of for whatever reason [18:08] seb128: what do you think would be a good time frame? [18:08] rickspencer3: what about the analysis phase? ie. should a bug be assigned to someone that's trying to determine the cause? then unassigned if it's too invasive, not possible to fix? [18:09] both as a tool for yourself to track your work, as a means to say "no" to more work, and for release management [18:09] rickspencer3: as said "current cycle" is my usual metric [18:09] time frame> karmic beta? [18:09] and release team ... so unassign everything that isnt on release team radar maybe. [18:09] "karmic" [18:09] awe: that's fine [18:09] if you have a bug which you realistically aren't going to work on, it's _much_ better to unassign yourself [18:09] let's start with seb128's definition of "near future" = current release [18:10] I don't like the idea of using assignment for tracking my work, for a couple reasons... [18:10] that way it's clear for others that nobody owns it, and that it's free for community involvement [18:10] awe: that sounds fine to me [18:10] bryce: I'm curious, why? [18:10] bryce: funny... that is exactly what i want to use it for :) [18:10] 1. many of the high importance bugs I work on get a CRAPLOAD of bug mail, and I don't want to be buried by it (e.g. the freeze bugs, the perf bugs...) [18:10] and the definition actually:) [18:10] bryce: what other way to track your tasks do you use? [18:10] I find +assignedbugs a very valuable tool [18:11] 2. I work on a lot of bugs without wanting to *commit* to fixing them, until a patch is available and proven to work [18:11] bryce: but that's a question of filtering, not keeping a realistic +assignedbugs list, certainly? [18:11] 2. sounds like a case for subscription, not assignment [18:11] pitti: filtering? === onestone_ is now known as onestone [18:12] pitti: do you use milestones to denote bugs that are committed to being fixed? [18:12] bryce: routing that bug mail to a different mailbox [18:12] awe: very seldomly; only for the crucial release blockers [18:12] awe: if I commit to fix a bug, I assign it [18:12] pitti: well mail from assigned bugs goes to my INBOX (same as subscribed bugs) [18:12] awe: conversely, if I say "I won't work on that", I unassign [18:13] bryce: but if you are working on them, don't you want them? [18:13] pitti: erm, you've seen that 500+ comment x freeze bug ;-) [18:13] I think that there is a legitimate need on the part of stake holders to be able to look at the current set of bugs, and know what is being worked, what is not being worked on, what won't be worked on, etc... [18:13] I suspect this will take some effort on our part to be consistent in how we handle bugs [18:14] there are too many ambiguous states right now that a bug can get into [18:14] this creates a lot of work and confusion [18:14] thoughts? [18:15] bryce: yeah, but most of it was just "look and delete" fortunately :) [18:15] bryce: so, if the bug mail is a problem, my feeling is that this is a different problem than the assignment of bugs; WDYT? [18:16] bryce: for instance, the fact that you and seb128 and asac each handle bugs differently means that I have to know your idiosyncrasies to understand the "bugscape" and well as the status of individual bugs [18:16] s/I/everyone/ [18:17] bryce: I'm curious, how do you track the ones you work on then? [18:17] pitti: it may be a different problem, but if so we need a better way of managing it... [18:17] i think it is important that everyone agrees on the state assigned, and i think the general user base thinks that means someone is working on it or planning to work on it [18:17] rickspencer3: what do you try to track? things we are working on and things important for the next milestone I guess? [18:18] so milestoned bugs and assigned bugs? [18:18] seb128: I think different people looking at the bugs have different needs [18:18] ie what is the problem we try to solve? [18:18] pitti: I usually use queries/reports heavily to identify bugs to work on, and maintain a todo list of ones I'm tracking closely [18:19] okay, I think we need a deeper dive on this than we will be able to get here [18:19] pitti: I used to use 'assigned' as my todo list of things I'm working on, but the two problems I mentioned earlier lead to me stopping [18:19] i think we can agree that we shouldnt be assigned to bugs if we are not working on them [18:19] seb128: we need a common workflow in order to work effectively [18:19] first for everyone to manage workload [18:19] also we already agree how to properly mark bugs so they get on the release team radar [18:19] so let's cut this off, but pick it up next week with more definition [18:19] for everything else we should really ask ourselve what we are trying to solve (like seb128 said) [18:20] * rickspencer3 sorry to have opened a can of works without a broom handy [18:20] and second, if someone (release team, me, you) assign a bug to someone else, we need some commitment to get a reply, a fix, or an unassignment [18:20] lol [18:20] pitti: I don't think you can fit differently minds in a same workflow though [18:20] i think pitti's reason is valid. but that means: "assignment == commitment to respond" and not "fix" [18:20] everybody has a workflow adapted to the way he,she is working [18:21] or thinking [18:21] For my part, I strongly agree with pitti on this point [18:21] can we pick this up next week? [18:21] * bryce agrees with seb128 [18:21] sure [18:21] I'm happy to keep discussing that here out of the meeting too [18:21] but if everyone has an arbitrarily different method, it doesn't help anyone either [18:22] right, which is why we should start by stating what are the issue and what we try to solve [18:22] ie "we don't have a coherent way to track what tasks are being worked right now" [18:22] just "people work differently" is not an issue [18:22] right [18:22] "track tasks being worked on" is a very important piece here [18:23] both for you and for anyone else [18:23] yes, I agree [18:23] I'm just trying to understand the scope of what you try to achieve [18:23] there is a set of problems, and we should do well to define those [18:23] is that the only goal? [18:23] bugs which have an assignee, and nto being worked on for years is obviously bad [18:23] right too [18:23] can we get a list of those issues [18:23] then we can work on adressing the issues [18:23] and if your +assignedbugs is 500 items, it's useless for you to manage your work [18:23] ? [18:23] internal partners don't know what the status of bugs mean [18:24] I agree with all that [18:24] I would say that if the goal is to track what people are working on, there's probably much better ways than using bug assignment [18:24] users have unrealistic expectations about how bugs will be handled and solved [18:24] it's not about users, it's about us [18:24] there is no way to assess the general quality of the project [18:24] individual engineers have no way to control their bug related work load [18:24] let's defer this discussion to after meeting with interested people? [18:24] and reschedule for next week? [18:25] ok [18:25] etc... [18:25] seb128: right [18:25] so we have a better scope next week? [18:25] +1 [18:25] +1 [18:25] good [18:25] almost done [18:26] speaking of bugs, I see a slew of assigned *and* release targeted bugs for releases going back to dapper [18:26] should I be concerned? [18:26] (see wiki page for the lists) [18:26] we should probably review the list and clean those [18:26] rickspencer3: that happens a lot [18:27] this is maybe a little too close to the last topic [18:27] so let's move on? [18:27] next: Team Meeting: Eastern Edition [18:27] * Luke, Robert, and I will be arranging a secondary team meeting to follow up from the main one. [18:27] * This is designed to ensure that everyone stays up to date, without the need to disrupt their sleep. [18:27] * Anyone else interested in joining, feel free [18:27] ArneGoetje: ? [18:27] this will be weekly as well [18:27] rickspencer3: depends on the meeting time [18:28] what time? [18:28] asac: ArneGoetje: I left that to Luke and Robert to decide [18:28] I presume it will be in my evening, their morning, and your middle of the night [18:28] depends of the middle of the night [18:29] if that's around midnight I will probably join some of those [18:29] rickspencer3: let's see what they come up with. [18:29] if that's later probably not [18:29] ArneGoetje: seb128: asac: feel free to discuss with them [18:29] anyway let's see what they pick [18:29] ok [18:29] any other business? [18:30] no [18:30] nope [18:31] sweet [18:31] welcome to Karmic! [18:31] Jaunty is solid, Karmic will be cosmic! [18:31] an interesting release indeed [18:31] solid> especially with the 965 bugs finally being fixed in proposed, *phew* [18:31] thanks all [18:32] pitti: it was solid anyway, as that bug was mitigated, but I agree, it will be even better when that works it's way to the desktops [18:32] ;-) [18:33] * rickspencer3 taps gavel [18:34] thanks all [18:34] thanks and good night [18:34] thanks [18:34] thanks [18:34] ArneGoetje: sleep well [18:35] so somebody want to continue on the bug workflow discussion? [18:35] seb128: sure [18:35] seb128: how do you track bugs you're working on? [18:35] I assign those to myself ;-) [18:35] every time? [18:35] * pitti does that [18:35] yes, I don't work on so many bugs [18:36] what else could "assigned' mean? [18:36] things I want to track for a cycle or wait on upstream I use milestones [18:36] https://bugs.edge.launchpad.net/~pitti/+assignedbugs?orderby=status <- my daily tool to manage my work [18:36] seb128: +1 [18:36] I've 2 categories: the bugs I work on, and the ubuntu-desktop bugs that need to be solved for this cycle [18:36] the first one == assignement [18:36] the second one == team assignement + milestone [18:37] ie "that's a desktop team bug to track for karmic" [18:37] seb128: what happens if the ubuntu-desktop bugs don't get fixed? [18:37] if you wait on upstream, then the bug should have an upstream tasks, and you are subscribed [18:37] rickspencer3: I update the milestone or unset it [18:38] seb128: how do you define "bugs I work on"? [18:38] rickspencer3: to reflect whether we still want to track the bug or if it missed the target [18:38] so the ubuntu-dekstop bugs are ones that you are signalling are valid, but won't get fixed unless someone steps up? [18:39] bryce: things I will do myself and upload, ie "nautilus is ftbfs due to gtk changes" [18:39] assignment means: ok, I will look at it and fix it soon [18:39] rickspencer3: yes [18:39] rickspencer3: that's my way to track "desktop-ish issues" [18:40] seb128: can't assignment also mean, i need to look at it and figure out what's broken first? [18:40] desktop-team bugs is primarily a means of sorting bugs, not trackign work on it, right? [18:40] that's sort of workarounding a launchpad bug or lack of feature though [18:40] "team assignment" as such doesn't have a well-defined meaning [18:40] pitti: no, it's a primary way to define things under a scope [18:40] seb128: right, that's what I meant [18:41] ie it's in the desktop team land [18:41] yep [18:41] I want to keep an overview on that land ;-) [18:41] which doesn't mean I will fix everything [18:41] but I watch what get fixed upstream, try to push to get those fixed, and look there for my next tasks too [18:42] or for contributor tasks [18:42] ideally launchpad would have a "give me all the milestoned bugs for the product this team is interested in" [18:43] I think I wrote a script to do that query [18:44] ie all the milestoned bug for the components listed on https://bugs.edge.launchpad.net/~desktop-bugs/+packagebugs [18:44] anyway that's sort of orthogonal to the discussion [18:44] bryce: cool is it online somewhere? [18:44] seb128: how do you handle bugs where someone else asks you to look into the bug (perhaps they assign to you), but you do not have a fix for it on hand? Do you simply unsub yourself at that point? [18:44] bryce: how do you define assigned tasks and how do you track those? [18:45] bryce: I try to look at it in a reasonable timeframe and unassign myself if I'm not going to fix it soon [18:45] that's what pitti said about being honest about what you are going to do on it [18:46] if you are too busy to fix it in the next month you can as well unassign and add a comment saying so [18:46] so nobody is holding is breath waiting for it to fix a bug which is assigned to you [18:46] yeah... I also unassign myself after a while, but I feel badly since they evidently wanted it fixed really badly. But if a fix is not easily at hand, there's a limited amount of time I can afford to invest [18:47] well, would you feel better making them think you are going to fix it soon for 6 month until they realize you are too busy for that? [18:47] in such case I just milestone the bug to show I think it's important for this cycle and stay on the radar [18:47] bryce: unfortunately urgency and time/ability don't always match perfectly :/ [18:47] but I un-assign myself at the same time [18:47] seb128: I would say that the bulk of my day-to-day work does not involve "assigned" bugs. Rather, I review lists of bugs looking for "targets of opportunity". E.g., it is fixed upstream, or a patch is attached, or someone mentions a git id that fixes it, or there is an interesting comment. [18:48] bryce: you don't work on fixes yourself usually? [18:48] I do that a lot [18:48] I tend to almost never assign myself bugs to be honest [18:48] that "watching out" is a good case for subscribing indeed [18:48] so for those you shouldn't assign it to you [18:48] until a patch is available, and your task is to actually deploy it [18:48] I grab the bug, work on it for a bit (usually no more than a couple hours), and then either it is fixed, or upstreamed, or I give the reporter additional tasks. [18:48] good [18:48] seb128, bryce: for you that actually makes sense, I think [18:49] I don't bother assigning myself, because if it gets fixed upstream or if the reporter completes their task, it will reappear in my queries [18:49] which means you don't have specific tasks assigned [18:49] I'm actually much more concerned about people having 500 bugs assigned thatn people who have 5 [18:49] so you are fine getting some bugs assigned [18:49] I don't mind the latter, but I do mind the former [18:49] I do assign myself if it is something I definitely need to follow up on - like a bug affecting lots of people, or that a manager has asked me to look into specifically [18:49] ie "intel 965 + compiz == freeze to fix for jaunty" [18:50] ok [18:50] so it seems you are in agreement with pitti and me on how to use assignment [18:50] just ignore it most of the time and do your daily work [18:50] pitti: yes I also work on some fixes myself, usually either packaging things, or patches for apport crashes, or quirks, or other "simple" coding tasks that rarely take more than a couple hours [18:50] but for things you are really going to look at, ie the 965 issue assign the bug [18:50] it seems we are actually in violent agreement then [18:50] yes [18:51] you need to talk to asac [18:51] TBH I was a bit confused about the "bug assignment is not the right way to track bug assignment" thing [18:51] occasionally I will work coding something more intricate but usually only in conjunction with upstream, and that work is usually outside the scope of a bug report [18:51] he seem to assign himself all the "would be nice to get fixed" issues [18:52] https://bugs.edge.launchpad.net/~seb128/+assignedbugs?orderby=status and https://bugs.edge.launchpad.net/~bryceharrington/+assignedbugs?orderby=status look quite reasonable to me [18:53] seb128, pitti: yeah it seems our workflows aren't that different [18:53] I notice seb128 has exactly 12 bugs assigned, which I laugh because that's my target to keep my assigned list to ~12 bugs max :-) [18:53] https://bugs.edge.launchpad.net/~asac/+assignedbugs?orderby=status has 115 [18:53] it's a lot, but then again, asac does get a lot of them fixed [18:53] asac is the crazy one :) [18:54] pitti: he should be able to assign some of those to me. ;) [18:54] yeah, seem we agree there [18:54] I've the feeling asac use assignement as I use milestone [18:54] right, that makes sense [18:54] ie for bugs to look at for the cycle [18:54] if asac is actually able to burn through those 115, it's a valid list, I think [18:54] hum diner time [18:54] bbl [18:54] pitti: yeah and if you exclude the inkscape bugs (upstream work) and just look at my assigned ubuntu bugs, it is 9 :-) [18:55] pitti: well then do we define it as a list of things we plan to do or things we are working on? [18:55] http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.htmlhttp://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html -> asac fixed 75 bugs in jaunty [18:55] ! [18:55] so 115 seems a little too ambitious [18:55] rickspencer3: ? [18:55] pitti: regarding "bug assignment is not the right..." [18:56] pitti: what I meant was that if the objective is to track "what is being worked on", as was mentioned earlier, "bug assignment" may not track that - like seb128 and I discussed, the bulk of our work is not around assigned bugs but rather a different mechanism, so assignments would not actually track the real work being done [18:57] bryce: I concur (we have blueprints and work items, etc. for that) [18:57] bryce: I meant "what's being worked on" in the bugs context [18:57] right [18:57] I would think it would track "bugs I intend to fix" [18:57] pitti: no I also mean in the bugs context [18:57] pitti: as i said above, i didnt use assignment effectively in the past (just mail prioritization) [18:57] bryce: so bugs you are monitoring, you are working on, but aren't assigned [18:58] bryce: my primary concern is "you actually work on assigned bugs", not "you have assigned bugs for everything you work on" [18:58] but i want to try again and think all assignments except those being release critical can be unassigned [18:58] pitti: well put [18:58] asac: well, 115 isn't totally unmanageable; if you unassign some 40 which you aren't realistically working on, that should be fine [18:59] but even if not, [18:59] pitti: "you actually work on assigned bugs" - explain this more [18:59] ok i can go through them manually. [18:59] it's still possible to visually go through a list of 115 and grab a thing to work on [18:59] bryce: "you don't have bugs assigned for two years and never look at them" [19:01] pitti: I'm trying to understand the motivation... is it just that we don't want to communicate to users that we are working on bug 123 because it is assigned to joe, when it's been sitting on joe's list for forever? [19:01] Launchpad bug 123 in rosetta "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123 [19:02] pitti: or is the motivation that as a manager you need a way to track workloads? Or a mechanism for driving specific bugs to a fix, in priority to other day-to-day work the engineer is doing? [19:02] pitti: this qa list seems to be "just" bugs targetted for release? [19:03] asac: no, that was bugs we fixed through changelog entries during jaunty; part of the "bug squashing" effort [19:04] pitti: sure? i checked like 12 random bugs and all were targetted [19:04] bryce: for me, the motivation is: (1) if you look at a bug and it's assigned, then it'll be worked on (with "work on" -> debug, fix, upload, or just commented and unassigned) [19:04] (2) be able to manage your own work during the day and week [19:04] ok i think i found a "not-targetted" bug [19:04] all fine [19:04] asac: I think you use targetting a lot [19:04] so maybe it's just that [19:05] i tried random bugs :). anyway. all fine [19:05] bryce: "driving specific bugs to a fix" is part of that [19:06] bryce: e. g. if we earn a canonical-desktop-team bug, and I assign it to someone, I'd like to expect that you fix it, forward it to upstream, or unassign it with a comment [19:06] bryce: (with "I" really being "any developer", ideally) [19:07] pitti: ok, I think (1) is adequately covered and reasonably consistent across the team already... is that correct? Or are improvements still needed with that? [19:08] bryce: yes, I think so; during the meeting that seemed contentious, but seems it was primarily a misunderstanding [19:09] regarding (2), I'm still a bit fuzzy... like we discussed earlier, seb128 and my day-to-day workflow doesn't seem to fit too well with doing assignments; again I think if we want to manage or track workload, there may be other approaches that impose less overhead. But maybe you should elaborate on your thinking since I suspect I'm not following [19:10] bryce: I agree [19:11] bryce: I basically do the same, just with different intensity [19:11] ok violent agreement again :-) [19:11] I am subscribed to some 500 bugs [19:11] yeah I'm subbed to quite a mess myself. [19:11] and if one of them gets a patch, etc., I'll review and handle it, and then assign it to me [19:11] but I guess you spend 90% of your bug time on such "opportunities" [19:12] while I spend 80% of my bug time on writing patches [19:15] * bryce nods [19:16] meh, got disconnected apparently [19:16] bryce: would you agree that subscribing (but not assigning) such bugs is the preferred approach? [19:16] yes, that's often what I do [19:17] right, so violent agreement [19:17] kthxdinner :) [19:17] cya [19:17] bryce, seb128, asac: thanks for the discussion [19:17] welcome [19:18] i am dropping out too for a while ... bbl === rickspencer3 is now known as rickspencer3-afk === kalon33 is now known as kalon33-eating [20:07] bah, debian GNOME packages keep adding delta over upstream for no good reason [20:07] pochu: any reason why you need to move the autostart file to usr? [20:08] seb128: it has translations which change every upstream release [20:08] and? [20:09] how is that an issue? [20:09] seb128: http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00305.html [20:09] and why was it ok before and does it required diff over upstream now? [20:09] because before they were in /usr/share/gnome/autostart/ [20:09] *shrug* [20:10] there is quite some desktop in etc for several cycle [20:10] I think we should just stop resyncing on debian, that's just not worth it, they keep adding stupid changes just because Josselin likes to do things his way [20:10] if it's wrong, reply to his mail in desktop-devel-list [20:11] I don't care enough to argue with him [20:12] I just think it doesn't make sense for debian to run into diverting everything from upstream without waiting for a reply [20:12] there is ton of recent changes not sent upstream or debian specific, debian will be the most patched distro soon where it should be nearer from upstream ideally [20:14] well, you're right that we should wait whenever possible and make the changes upstream first, but that doesn't mean we should stop applying patches or proposing changes [20:15] and waiting for a reply -> you know that's usually not possible, the policy even here is "forward it and apply it, we can revert later" [20:15] right, there is just lot of recent random changes which are not really required but pushed quickly anyway [20:15] so he forwarded it, but nobody seems interested... [20:15] and without being forwarded upstream often [20:15] if everybody doesn't agree but they don't want to discuss it... [20:15] right, which means maybe he's not right if nobody agrees [20:16] it's not that nobody agrees, it's that nobody cares [20:16] which is different [20:16] I'm not going to apply those changes in ubuntu anyway [20:16] well, if nobody cares really that's because nobody sees that as a real issue [20:16] so is it really worth the distro delta? [20:17] we don't do those change and have autostart in etc for over a year [20:17] and nobody ever complain until now [20:17] we should probably discuss this in #gnome-debian :-) [20:17] no, I know how it's going to turn [20:18] Josselin is anti-ubuntu since the start and will be happy to do the thing in a way which we will not do only to annoy us [20:18] he's switching all the python packaging for no good reason to his system too for example [20:19] that's not him, it's everybody [20:19] he started some years ago without good reason when nobody was doing it [20:20] anyway I don't want to polemic on that [20:20] well, pysupport is better than pycentral for a long time, and he maintains pysupport, so that sound like two good reasons to me [20:20] I'm just saying that it's a shame that debian distro patch that quickly for things not required [20:20] anyway, I don't really care about this, you don't need to sync what you don't want to [20:21] pochu: "he imposes what is working on" is not really a justification to create not required changes on things which are working [20:21] maybe, but there's still the other one [21:10] pitti: where did you get the build failure for telepathy-glib, debuild or pbuilder? [21:10] it builds locally for me... i will try with pbuilder too [21:10] kenvandine: on the buildds [21:10] kenvandine: https://edge.launchpad.net/ubuntu/+source/telepathy-glib/0.7.31-1 [21:11] http://launchpadlibrarian.net/27394651/buildlog_ubuntu-karmic-i386.telepathy-glib_0.7.31-1_FAILEDTOBUILD.txt.gz [21:19] great, a seg fault in the test suite when running on the buildds that doesn't happen locally [21:20] oh... interesting... it does fail locally... but not during the build [21:21] kenvandine: the previous version built, so it might give a clue to look at the diff [21:21] i know why [21:21] kenvandine: also, we could just retry the build [21:21] the previous version didn't run the tests [21:21] ah, heh [21:22] kenvandine: does it fail on debian's buildds as well? [21:22] dunno [21:22] i have it failing locally now [21:22] running the specific test [21:22] * kenvandine debugs [21:23] pitti: can you look at the telepathy-mission-control MIR again? [21:23] make sure it is ok before i touch them all up? [21:23] kenvandine: yes, will do (got the mail) [21:23] thx [21:24] kenvandine: you checked for user-visible strings? (uses gettext, etc.) [21:25] kenvandine: looks good now [21:25] it has no UI :) [21:25] kenvandine: btw, did you know that on wiki.u.c. you can just write "Bug:12345" to get a bug link? [21:25] no [21:25] thx :) [21:25] kenvandine: well "no UI" != "no user visible strings" [21:25] ok, good point [21:25] there is a cli program [21:25] kenvandine: thanks for the updated review, I'll process it tomorrow morning [21:25] but it doesn't appear translated [21:26] i'll note that [21:26] kenvandine: ok, that doesn't hurt [21:26] kenvandine: I'm more concerned about things like _("Connected") or so, states that the library provides to GUI consumers [21:26] none of that [21:26] or standard error messages [21:26] messages appear to be in the client [21:37] ok, telepathy-glib bug filed upstream === kalon33-eating is now known as kalon33_ === kalon33_ is now known as kalon33-sleeping === kalon33-sleeping is now known as kalon33-packagin === kalon33-packagin is now known as kalon33 [21:44] good night everyone [21:45] good night pitti === Ampelbein is now known as Ampelbein_ === Ampelbein_ is now known as Ampelbein [21:52] night pitti === rickspencer3-afk is now known as rickspencer3 [22:14] asac: around? [22:16] sure [22:16] crevette: bluez? [22:16] ;) [22:17] it is for the patch http://bugzilla.gnome.org/show_bug.cgi?id=584857, I thought I had found but finally not ... [22:17] Gnome bug 584857 in general "[patch] support notification deamon without actions capabilities" [Normal,New] [22:19] hmmm [22:19] I found perhaps [22:22] asac: I should use "if (g_list_find_custom(caps, "actions", (GCompareFunc)g_strcmp0) != NULL)" ? [22:24] it's late, I need some sleep [22:25] see you === hggdh is now known as hggdh_ === hggdh_ is now known as hggdh__ === hggdh__ is now known as hggdh