[00:00] we need to get round to transferring mvo from desktop so that he can answer this sort of question. :) [00:01] :-) [00:01] asac: I suggest mailing Michael and/or ubuntu-devel [00:01] ok, we're at time [00:02] only thing I forgot is to remind folks that I'll be away next week on a music course [00:02] have fun cjwatson [00:02] asac: I've got it now, I killed update-notifier and restarted then waited a while [00:02] have fun releasing alpha 4 without me :) [00:02] and I'm at DebConf, so pitti is the designated release nagger^W manager for alpha-4 [00:02] I'm away for a long weekend, back on Wednesday [00:02] * evand notes that he will be away from tonight until next sunday [00:03] at DebConf next week, that is; I'll still be around to nag people this week :) [00:03] oops. noone left for alpha 4 ;) [00:03] yes, we'll be very lightly staffed in general next week [00:03] * asac runs ;) [00:03] slangasek: I'm sure you could manage to nag remotely as well [00:03] there's aKademy too [00:03] james_w: from experience, I don't expect to have the spare attention circuits :) [00:04] slangasek: just nagging in spirit then? [00:04] slangasek needs a nagbot [00:04] heh [00:04] will be bumping all the OOo a4 bugs back a bit unless OOo 3.0rc1 is released magically on Aug 8 [00:04] james_w: yes :-) [00:05] maybe we could make slangasek obsolete with a tiny bash script? [00:05] oh, adjourned, in case it wasn't obvious [00:05] thanks, all :) [00:05] thanks all [00:05] thanks! [00:05] thanks [00:05] heh thanks all. [00:05] thanks [00:05] thanks [00:05] thanks === evand is now known as evand|vacation [00:05] though I think we should continue mocking slangasek unofficially [00:05] * TheMuso heads to the store to get some more milk... [00:05] james_w, agreed [00:05] surely slangasek would need to be replaced with a POSIX sh script rather than bash [00:06] wouldn't do to be standards-uncompliant [00:06] thanks! [00:06] heh [00:06] so I never will replace slangasek =) [00:07] hmm, my 121 line nagger script is written for bash, so it's not useful for this, too bad :) [00:08] * liw nags himself to bed, good night === Rinchen` is now known as Rinchen === johnc4511 is now known as johnc === johnc is now known as johnc4510 === techno_freak is now known as technofreak|woun === technofreak|woun is now known as technofreak|hurt === sabdf1 is now known as sabdfl_ === sabdfl_ is now known as sabdfl === sabdfl is now known as sabdfl_ === dholbach_ is now known as dholbach === ogra_ is now known as ogra === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Ubuntu Mobile Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 07 Aug 14:00 UTC: Ubuntu Java Team | 08 Aug 00:00 UTC: Americas Board | 08 Aug 04:00 UTC: Ubuntu MOTU | 08 Aug 15:00 UTC: Ubuntu Release | 10 Aug 21:00 UTC: Arizona LoCo IRC [12:51] Mobile Team Meeting time? [12:51] In about 10 minutes. [12:58] Indeed, about 3 minutes now :-) [13:00] #startmeeting [13:00] Meeting started at 07:04. The chair is davidm. [13:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [13:00] Hello everyone [13:01] Good morning [13:01] The ubuntu mobile meeting is started [13:01] Hey [13:02] We have no action items listed from last week, persia since you chaired the meeting is there anything I'm not aware of? [13:02] * ogra waves [13:03] davidm: Oughtn't be. The only big item on the agenda was moving the meeting time. [13:03] OK, just checking [13:03] I just pinged StevenK to join us. [13:06] There is no new business on the wiki but I had a heck of a time getting the pages up they switched the wiki over to openid yesterday [13:06] So I'm not surprised that there is nothing there. [13:07] persia, StevenK lool any issues we should talk about? [13:07] ogra, ^^ [13:07] Not that I'm aware of [13:07] (yet :-) [13:07] One thing that came up a couple days ago was perhaps doing a review of the seeds to see if we have the right package mix for intrepid. [13:07] I'm happy to report I'll be attending the Maemo Summit in Berlin, mid-September [13:07] Oh yes. Are people happy with my seed changes? [13:08] lool, great [13:08] I fiddled with a chroot, and things seem to be good, but it might need some hints to determine if that's what we want to be testing against come FeatureFreeze at the end of the month. [13:08] * ogra left his atom classmate idling the last two days ... by the looks of it in idle state generic is taking similar amounts of battery than lpia both survive about 6h [13:08] just fyi [13:09] ogra, thanks for that info. [13:09] persia: The mobile or the mid seed? [13:09] not sure what happens during actual usage [13:09] lool: Yes. [13:10] persia: So both, ok [13:10] Since we have some time in this meeting, I'd love it if we could take some minutes to check progress of intrepid tasks: merge of ppa, installer, images etc. [13:10] ogra: "generic" == i386? [13:10] no -generic [13:10] == 586 [13:11] Yeah, but dpkg-arch-wise [13:11] lool, good idea [13:11] Unless I've missed something (entirely possible), the non-hildon stuff should all be merged from the PPA. [13:11] [topic] status of intrepid tasks: merge of ppa, installer, images etc. [13:11] New Topic: status of intrepid tasks: merge of ppa, installer, images etc. [13:12] persia: Could you list what remains to be done on the merge front? [13:12] * ogra would like to actualy get some assigned beyond "jump in where gaps are" :) [13:12] I understand MIC, perhaps xulrunner ? [13:13] ogra: Oh you're bored? *cliketeeclick* I'll find you something :-P [13:13] Ah, well, there's the ones I didn't touch: xulrunner, libdrm, and similar. I don't currently have access to the tracking data I was using for merges previously, but may be able to recover it if a full list is desired. [13:13] classmate has the release candidate out and i only have compcache left to implementation in the platform team ... so unless any weird additional classmate stuff comes u i'm free [13:13] *to implement [13:13] ogra: Can you make -mobile not be a copy of -desktop, look nice, and work? [13:14] persia: Could we go into more details? I'm pretty sure we wont merge psb and libdrm: psb needs the special libdrm and intel needs to provide updated drivers first [13:14] persia, sure :) if someone dfines the corner points of "look nice" [13:14] We need updated drivers for the kernel, an update on upstream libdrm status as to rebase needed libdrm patches, and then we can push -psb to intrepid [13:14] persia: Concerning xulrunner, we should discuss this with asac [13:15] If necessary, we should drop the gconf backend if that can't be merged [13:15] lool: Erm. Has TTM or GEM landed in upstream libdrm? I hadn't heard of any clear plans to do so within the intrepid timeframe. [13:15] bryce would know. [13:15] persia: I don't know what the plans are either; I don't think psb is using any of the two though [13:16] I thought psb was using HEAD, which was TTM in late May/early June. [13:16] * persia looks through old mail [13:16] I think it's using HEAD too, but I don't know whether it's relying on any memory manager stuff or doing modesettings [13:17] Anyway, not our problem; Intel needs to rebase on upstream and tell us what they rely upon for 2.6.26 stuff IMO; the ball is on their side for psb driver support AIUI [13:17] If it's using HEAD, it would be using the new memory manager stuff, as I understand it, the old way and the new way of handling VRAM are different semantics. [13:18] Ok; well, in both cases it's to Intel to tell us what they are using; we don't have to sort out what their upstream drivers should be or were or will be using [13:18] So, that leaves in the NOT MERGING status language-pack-gnome-* which ought be useless and derive from rosetta, grub, which patch is reported as "unsafe". [13:19] moko, which is obsolete, and keyring, which doesn't mean anything without a special archive. [13:19] The grub patch I'm afraid we will drop; it will remain in the librarian for posterity, but it's unlikely to be merged in the current grub upstream and it wont work with grub2 [13:19] lool, the prob is that pulling in an uncommon drm module will break all other drm drivers [13:19] Concerning the langpacks, I'm not sure these are obsolete; I suspect we need some integration work to get them integrated in intrepid [13:20] ogra: We wont be pulling the psb drm anymore [13:20] so we should be intrested what they base on indeed :) [13:20] ah, k [13:20] Note that nouveau waits on HEAD as well. It's just a matter of porting all the rest of the drivers [13:20] Until they rebase it [13:20] * ogra missed that [13:20] ogra: I mean, as long as we don't get any drivers information from intel, we will remain with the upstream kernel bits [13:20] good [13:21] well, basing everything on HEAD would indeed be preferable ... [13:21] I'll doublecheck with ChickenCutClass [13:21] but i guess that extends the intrepid tieframe if we have to do it ourselves [13:21] *time [13:22] persia: So on the merge front status is: xulrunner gconf backend needs merging (lool to discuss with asac); langpacks (lool to discuss with asac); MIC (may I assign this to you?) [13:22] moko, keyring, grub, to be dropped [13:22] lool: MIC was uploaded 80 minutes ago. langpacks should be useless if there's not a separate PPA: the standard infrastructure should handle them. [13:22] As well as psb/libdrm/kernel bits [13:23] persia: I'm not sure the standard infrastructure currently ships the midbrowser bits [13:23] I'm not sure about xulrunner, and I'll try to get my melting system up to see if there's anything else interesting not merged. [13:23] The /usr/lib/midbrowser xulrunner extension [13:23] Ok; anything else on the topic of merging ppa to intrepid? [13:23] lool: In the langpacks? [13:23] persia: In the langpacks [13:24] I'll look again. It ought. [13:24] Ok; let's move to kernel, I see amitk joined us [13:25] Note that langpacks only work for main: we may need a few MIRs if something is missing. [13:25] amitk: I understand linux-lpia is now in the hands of Michael [13:25] lool: that's right [13:25] I'm not sure whether the Ubuntu kernel team worked on armel support already; I don't think we have any requirement to do so yet, so it might be a task with a lesser priority? [13:26] lool, no requirement as yet. [13:27] lool: I will have a armel git tree available in the next 2 weeks. I am about to use debian bootstraps to see if it works. [13:27] amitk: Great [13:28] amitk: I'm not sure whether there's anything else on the pure-kernel topics, I know I wanted to support lpia udebs and that required kernel udebs, but I don't think this was on your plate [13:28] amitk: Perhaps we shoudl discuss drivers shortly [13:28] amitk: Any drivers you're working on for mid/mobile devices for intrepid or hardy? [13:29] lool: I have added support in the intrepid tree for udebs before I passed it on to Michael [13:29] cool [13:29] amitk: Excellen [13:29] t [13:30] http://kernel.ubuntu.com/git?p=amitk/ubuntu-intrepid-lpia.git;a=summary [13:30] LINK received: http://kernel.ubuntu.com/git?p=amitk/ubuntu-intrepid-lpia.git;a=summary [13:30] ^ for anyone interest in playing with intrepid lpia [13:31] amitk: Cool! [13:32] amitk: Thanks for the updates [13:32] I'll publish the armel tree as soon as I have it booting on NSLU [13:32] StevenK: How are images going? Did infinity help setup dailies for intrepid? [13:32] oh, are lpia udebs in the archive yet? [13:32] cjwatson: Geez I can't believe you beep on "udeb" [13:32] :-P [13:33] I don't :-) [13:33] lool: I'm working on it, I keep getting distracted by Hardy [13:33] * persia is looking forward to udebs: current work to make an installer is happening on i386, which isn't ideal from the stanpoint of seeing the end results. [13:34] StevenK: What's the current status? Do you think it will require a lot of work to get dailies for intrepid? [13:34] oh, yes, they seem to be in the archive [13:34] I'll build debian-installer for lpia once I get half a chance then [13:34] cjwatson: they built -> https://edge.launchpad.net/ubuntu/+source/linux-lpia/2.6.26-1.1/+build/669803, not sure if they are in the archive though [13:34] cjwatson: Thank you. [13:35] aah good [13:36] lool: Not a great deal, no. Just requires I have some time :-) [13:37] StevenK: Okay [13:37] persia: Would you be tempted to talk about installer work? [13:38] lool: I've been fiddling with glade to get the desktop installer to work at 640x480 (just in case anyone wants to install on a very small screen). [13:38] Great! Scalable UI is a hot topic on Gtk+ channels these days :-) [13:39] That's nearly done, and I ought have something for evan to review shortly (although I'll not block on review). [13:39] Err, not exactly scalable, just smaller :) [13:39] Okay; anything else on installer? [13:39] a different UI or just the existing one adjusted ? [13:40] I've put off looking at the 2G/squashfs use case for now: I want to get something working for the larger class of devices first. [13:40] i could look into producing a udeb [13:40] For 2G/squashfs/reset capability there is a need for an additional d-i module, and I'm still wrapping my head around the d-i code. [13:40] for the size detection etc [13:40] ogra: If you want to chase that, it would be a great help. Thanks. [13:40] ok, on my TODO then [13:41] Once it exists, we can just feed it as part of the ubiquity preseed, and we ought be OK. [13:41] Ok; I'm sceptical on the time it would take on such devices to build the squashfs at install time, but that's not the place or time to discuss this [13:41] i did some udeb stuff before with ltsp, so shouldnt be a biggie ... and cjwatson didnt seem reluctant to the idea anymore :) [13:41] lool: Not build the squashfs at install time. I looked at that, but it's just infeasible. [13:41] Last topic which comes to my mind ATM would be on ogra's activities for intrepid: what are you up to? :-) [13:41] It's a matter of using the existing squashfs. [13:41] what would this new udeb do? [13:41] and it's unlikely that you'd want to use that udeb in ubiquity [13:42] if content > capacity -> copy squashfs, set up aufs and warn the user about upgradeability [13:42] if content < capacity -> copy content in place and configure [13:42] it already has its own perfectly good squashfs handling code [13:42] this is all in ubiquity? [13:42] In the case where we detected larger devices, we would have to remove the squashfs hints from the CD suashfs. [13:42] this was supposed to be a udeb [13:42] if d-i isn't involved, you should just do this in ubiquity/scripts/install.py, not a udeb [13:42] ubiquity would need a variable to skip the content copying i can preseed for that [13:43] or it could figure it out for itself ... [13:43] or that [13:43] ogra: Why not copy only the differing contents after setting up the unionfs on the target? [13:43] but that smells like more code changes to ubiquity [13:43] cjwatson: Evan advised me that ubiquity worked cleanest as a d-i front-end, and that we ought think of it as an advanced preseeding system, plus the possible facility to copy a livefs to reduce installation effort. [13:43] ogra: smells better, though [13:43] persia: this is true, but the copying part of ubiquity is very much not geared around using a udeb [13:43] i was planning to change ubiquity itself to the least amount i can ... but if you think thats better i can do it [13:44] :c [13:44] we use d-i components for all the configuration parts where possible [13:44] cjwatson: Ah, so if the copying was to be replaced, it shouldn't be done with a udeb, right? [13:44] the copying stage, though, is just done inline [13:44] persia: that would certainly not be my inclination [13:44] lool, copy content above would mean standard ubiquity [13:44] OK. That's easier then :) [13:44] lool, only in case where the content doesnt fit it shuld do a different setup [13:44] ogra: Ok; didn't know it could copy contents after setting up an unionfs on the target [13:45] lool: You can't. [13:45] no that must hapen before [13:45] I don't think you can support the 2G/squashfs case particularly sanely in d-i [13:45] lool: I'll explain the theoretical mechanism in #ubuntu-mobile after the meeting. [13:45] I mean, I know people have tried, but it's really geared towards building up the system from scratch [13:45] cjwatson, the advantage of a udeb is that oem's could just use it with d-i [13:45] persia: Ok, let's do this [13:46] where ubiquity might not be wanted [13:46] i.e. mass installs etc [13:46] ogra: but it would be much, much, much harder than just creating a udeb to make d-i work in this type of scenario [13:46] trust me, I've tried [13:46] * lool <15 minutes EOM warning> [13:46] ok [13:47] lots of bits of d-i would become essentially non-functional; for instance how do you do package selection when you have a squashfs? [13:47] there's really not a lot of point [13:47] Right, so anyway, with the udebs in place, and cjwatson's generous offer to do an lpia d-i build, I should have a working installer for -mid next week, for the >4G case. [13:47] right, no package selection in that case indeed [13:47] For the smaller case, we'll have to fiddle more, but at least there will be something to test (assuming we can build images) [13:47] and FWIW OEMs are already using ubiquity for mass installations [13:47] ok [13:47] hardy has a noninteractive mode [13:47] i always hought d-i would be easier for that :) [13:48] ubiquity noninteractive seems a lot easier than d-i+preseed for OEM use. [13:48] (i would take d-i if i were OEM ... :) ) [13:48] yeah, squashfs is likely faster than having package selection being installed [13:48] indeed [13:48] yeah, d-i just doesn't really work with a pre-existing filesystem [13:48] ogra: That makes it just a file copy, rather than repeating all the postinsts, etc. [13:49] so easier or not, ubiquity is what you've got ;-) [13:49] ok [13:49] sad :) i like shell more than python ... but will find my way around :) [13:49] [action] lool the investigation of xulrunner, langpacks and linux-lpia bits [13:49] ACTION received: lool the investigation of xulrunner, langpacks and linux-lpia bits [13:49] Thanks davidm [13:50] lool happy to do so. [13:50] If we are done with the installer, I'd love to use the remaining time to discuss ogra's work in intrepid [13:50] 10 minute warning [13:50] * ogra listens up [13:50] * persia also, especially any ideas for the -mobile seed [13:51] ogra: Well actually I was expecting you would give us (mostly me) an update on what your plans are, what you're currently working on for intrepid etc. [13:52] I don't have anything to throw at you at this minute, but I've noted that you have free cycles and will come up with tasks for you later on ;-) [13:52] well, i was tied in by classmate work and as i said have one task left for platform (compcache) which should be done mid next week [13:52] Okay; thanks for the update [13:53] Are you also merging classmate stuff into intrepid? [13:53] s/platform/foundations/ ;-) [13:53] I know you had an issue with merging the last kernel patches [13:53] as i understood persia he wants me to clean up the -mobile seed ... if that isnt supposed to be a copy of -desktop with different themeing for smaller sizes i need input on the apps that differ [13:53] cjwatson, oh, right :) [13:54] lool, the kernel team agreed to make my patches SRUable for the standard hardy kernel which should take the load off my sholders [13:54] intrepid has all these fixes in already [13:54] ogra: I think describing the new use of the mobile seed as "different theming for smaller sizes" is quite a good target; I guess we can remove applications which aren't useful in the subnotebook case or replace them with more netbook-friendly apps [13:54] ogra: Most of the apps seem to work with -desktop on my Kohjinsha, but menus are awkward, and some stuff doesn't work at 600 veritical pixels. [13:54] (no particular example in mind, but I thought we should go through the seed line by line with these criterions) [13:55] lool, well, ther are patches for apps that dont work (i.e. i'd like to look at evo and gdm patches) [13:55] Ok [13:55] * lool <5 minutes til EOM> [13:55] the question is if we can get them in in a sane way to not affect normal desktop usage [13:56] that will need some review [13:56] ogra: Probably the scalable UI stuff, really. [13:56] you mean the panning modes ? [13:57] that requires special X setup ... not sure i like to have it in a general setup [13:57] Ok; thanks everybody for the heads up on your work -- did I miss anybody, anything? [13:57] Either that, or something that doesn't assume 96 DPI and >10" screen so that one could use the information one has from the X server to drive app behaviour. [13:57] and also not sure how it will work with the new Xorg ... thats moving away from virtual desktops to be used for panning upstream [13:57] persia: You want to read the discussions on Gtk+'s em support [13:58] hi [13:58] lool: Yes I do: thanks for mentioning it earlier. [13:58] Ok; any other last minute topic? [13:58] hey pitti [13:58] hey seb128, mpt, ogra, lool [13:58] hello [13:58] looks like it's about time to end the meeting going once....................... [13:59] looks like it's about time to end the meeting going twice.......... [14:00] ooh, GTK em support? [14:00] #endmeeting [14:00] Meeting finished at 08:04. [14:00] Thanks everybody! Also thanks davidm for chairing! [14:00] lool, where could I find those discussions? [14:00] I like this time better :-) [14:00] mpt: Mentionned on Planet GNOME; grabbing the mail.gnome.org URL [14:00] davidm: you have to finish on time though ;) [14:01] http://mid.gmane.org/1218056830.3623.64.camel@x61.fubar.dk [14:01] Keybuk: Mootbot is 4 minutes ahead! [14:01] mpt, persia ^ [14:01] hello everybody [14:01] Keybuk, yes, I have to see why my time and MootBot differ [14:01] hey pedro_ [14:01] * mvo waves [14:01] thanks lool [14:01] I thought I was using ntp on my laptop :-/ [14:02] * lool wishes next meeting attendees a good meeting and leaves the stage [14:02] hi MacSlow, mvo [14:02] davidm: I read it as 1301Z [14:02] bwahaha [14:02] I can so ensure you finish your meeting on time ;) [14:02] annnnyway [14:03] hi [14:03] hey Riddell [14:04] https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-08-07 [14:04] after much battling with the wiki, I almost have an agenda [14:05] mpt: Did you see the em video in that message? Very cool. [14:05] so first thing on the agenda [14:05] mpt: Welcome Aboard! [14:06] mpt is now a full-time member of the team as our UI designer [14:06] \o/ [14:06] mpt++ [14:06] welcome! [14:06] * pitti hugs mpt [14:06] he is available for all of your UI needs [14:06] what video? [14:06] welcome mpt! [14:06] and will no doubt be coming to you with sketches and ideas [14:06] MacSlow: http://people.freedesktop.org/~david/gtk-resolution-indepence.ogg [14:07] mpt: welcome! [14:07] tedg1: that's doing scaling of controls by point size? [14:08] and we already are off-topic ;-) [14:08] Keybuk: Yes, and scaling of spacing. [14:08] shiny [14:08] Keybuk: Basically all "values" become EMs -- which covert to pixels based on point size. [14:08] pitti: thanks for doing last week's meeting while I was down with Turkish bugs [14:09] I see one action outstanding: [14:09] * Mirko to clarify gdm goals for face browser for Intrepid/Intrepid+1. [14:09] (I assume MacSlow? :p) [14:09] tedg1, very nice [14:09] Keybuk: you're welcome [14:09] Keybuk: I tend to use real names on !IRC... [14:10] pitti: no matter how badly spelled? :) [14:10] oh, it's Mirco? [14:10] * pitti hugs MacSlow, sorry [14:10] MacSlow: any update on the gdm goals? [14:10] Mirco is correct [14:11] Well, I don't think I can meet the feature-freeze deadline for the login-experience. [14:11] I saw your mail this morning [14:11] and I saw your mail last week outlining the missing bits [14:11] so I think we can consider that done? [14:12] The amount of "boiler-plate" code for a graphical-greeter is far more than I anticipated... partly also due to the lack of experience with GObject... never was forced to seriously use it before. [14:12] ok [14:12] mpt: also you were attempting to get in touch with the user admin people, any joy there so far? [14:12] no... it's not done [14:13] Keybuk: user admin? [14:13] who are the "user admin" people? [14:13] Keybuk, yes, they'd like my input. So it's up to you to put that it in the appropriate position on my priority list. :-) [14:13] MacSlow: I mean is the goals being clarified done? It looks to me like they are [14:13] mvo, Fedora developers at the moment [14:13] context? [14:13] * mvo nods [14:13] users-admin in something fedora doesn't use [14:14] s/in/is [14:14] so a modern replacement for the one that gnome-system-tools is providing now? [14:14] my +1 for getting a replacement for users-admin soon :) [14:14] Keybuk, you mean with upstream? [14:14] specifically Jon McCann and Matthias Clasen [14:14] mpt: you have design changes for the fedora ui? are they on the wiki somewhere? [14:14] mpt: can we get some context about what tool you are speaking about? [14:14] seele, seb128: http://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html [14:15] mpt: ah, thanks! [14:15] ok, that's something new, didn't know about that [14:15] mpt: right, i've seen that. it sounded like you had changes [14:15] pitti reviewed their tool some weeks ago and that was not something to use [14:15] seb128: oh, that was system-config-user [14:15] seb128: but they are planning a new one [14:15] seb128, James Westby raised it at this meeting three weeks ago. [14:15] pitti: right, I didn't know that ;-) [14:16] mpt: I think at this point new user admin is jazzy jaguar, so something to work on in the background [14:16] Keybuk, ah... ok read my report from last week again... now I know what you refered to... yes I know what's needed. The amount of work needed is not doable until feature-freeze. [14:16] ok [14:16] other agenda items [14:16] Riddell: libzip MIR [14:17] I saw a nag in your activity report [14:17] seele, not yet. :-) [14:17] slangasek: around? is there much of a backlog in MIRs at the moment? [14:17] I keep trying to nag jdstrand and kees, no result so far [14:17] mpt: right on, let me know if youre looking for feedback. i was thinking of doing the same for KDE once akademy is over [14:18] Keybuk: MIR are pitti and doko [14:18] no? [14:18] Riddell: if it's otherwise ok, we can turn it upside down, promote it now, and turn the bug into an intrepid milestoned bug for security [14:18] seb128: it is marked as 'needs security review' [14:18] what is the issue? duplication and having yet another code to do that? [14:19] it's on our list of things todo-- we've had some rather high priority stuff come up lately [14:19] that's of course always a general issue [14:19] unzip itself has had a number of issues, and it's certainly much better reviewed than libzip [14:19] ok, as long as it's not been dropped [14:19] pitti: that would help me [14:20] it sounds like this is on the TODO and will be done as soon as it can be [14:20] Keybuk: has been for two months.. [14:20] Riddell: can you please follow up on the MIR bug, or send mail? [14:20] pitti: if you have no objection to that fast track with your RM hat on, go for it [14:20] (just as a reminder) [14:20] pitti: ok [14:20] I tend to forget IRC pings, but I'm eager to get inbox zero and thus have to do stuff for that :) [14:21] ok [14:21] pitti: Team structure, member shuffling [14:22] that's actually a question [14:22] * tedg suffered atheros based netsplit, sorry [14:22] a while ago it was announced that some people will change teams [14:22] so I'm just curious about that, since it partly affects me as well (whom to ping for reports, which specs to watch, etc.) [14:23] ah, ok [14:23] it's probably been bounced around in various forums [14:23] I haven't seen any official announcement so far, I think [14:23] I'll attempt to outline the changes as best I can ;) [14:23] The first change is that Colin and I are stepping down as team managers [14:23] Colin will be taking the role of Technical Lead for the platform team [14:24] while I will be taking some currently untitled role in the platform team (proposed titles include Senior Engineer, Lead Developer, etc.) - basically a technical lead level position without the specific responsbility [14:24]