=== yofel_ is now known as yofel === st33med_ is now known as st33med === YDdraigGoch is now known as Richie === nxvl_ is now known as nxvl === Amaranth_ is now known as Amaranth === dholbach_ is now known as dholbach === jarlen_ is now known as jarlen [09:48] mornin [10:05] There is supposed to be a meeting isnt there/ [10:05] ? [10:06] which kind ? [10:06] Asia Oceania [10:09] perhaps. let me check the wiki apge [10:10] indeed [10:10] persia: ping [10:11] elky: ping [10:11] amachu isn't online [10:11] let me send a mail [10:11] Sounds good === juliux_ is now known as juliux === juliux is now known as Guest76509 [10:19] FFEMTcJ: sorry, noone seems to be around. next meeting will be in two weeks, but you're welcome to wait here for the rest of the hour just in case folk do show. [10:19] :-( [10:19] ok [10:19] thanks [10:24] or add yourself to one/both of the other membership boards and attend theirs if they are sooner [10:24] popey: ;-) [10:25] FFEMTcJ you did add yourself to the america's membership board aswell? [10:26] leoquant: they didnt get to me on the last meeting, so i was gonna try this one.. [10:26] yep [10:26] dunno when it'll be tho [10:29] lifeless there aren't any reserves who could lead membership approvals ad-hoc? [10:30] leoquant: we're not quorate right now. [10:32] how many does that take, out of curiosity? [10:33] FFEMTcJ afaik 4 [10:33] gotcha [10:36] lifeless: if you meet the # you need, please ping me.. [10:37] * popey volunteers if you need me lifeless [10:48] hi [10:58] amachu: hi there, meeting was an hour ago ;) [10:59] lifeless: yes [10:59] was there a quorum? [10:59] nope [10:59] there was Me! and that was all :( === asac_ is now known as asac [11:14] lifeless: ok. sorry for not making it. held up in a medical check up.. [11:14] fine let me make it remind all.. === ogra_ is now known as ogra [13:00] #startmeeting [13:00] Meeting started at 06:59. The chair is NCommander. [13:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [13:00] * NCommander waves to ogra persia StevenK asac davidm JamieBennett dyfet GrueMaster [13:01] I'm here [13:01] what? not at me? [13:01] * ogra is here [13:01] * GrueMaster snores loudly. [13:01] and plars [13:01] you hurt my feeling [13:01] how about you do that call before the startmeeting in the future (like we ask every week since ages :P ) [13:01] ogra, will do [13:02] thanks :) [13:02] since it can take a while to get everyone to show up... [13:02] plars, I apologize, by time I realize I forgot a name, you already responded :-/ [13:02] hello [13:03] NCommander: heh, was kidding [13:03] NCommander: hi [13:03] * ogra wonders if GrueMaster is to jetlagged to show up :) [13:03] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091124 [13:03] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091124 [13:03] odd ... calendar disagrees with time [13:03] he responded earlier [13:03] asac, Google and daylight savings don't agree [13:03] asac, yeah still DST issues i think [13:04] though i got a proper reminder today ... didnt have that the last times [13:04] ok [13:04] [topic] Action Item Review [13:04] New Topic: Action Item Review [13:04] [topic] ogra to report back on midori usability [13:04] New Topic: ogra to report back on midori usability [13:04] we did that at UDS [13:04] done ... [13:04] ah [13:04] ok [13:05] then there's one action item that didn't get answered [13:05] [topic] asac to talk to Nokia on their optimizations to gecko [13:05] New Topic: asac to talk to Nokia on their optimizations to gecko [13:05] yes. so UI frontend is closed source as it seems [13:05] obsolete after the UDS decision ? [13:05] so that makes it unsuitable [13:05] i mean we decided on chrome already anyway [13:05] ogra: well. for touch screen we still need something [13:05] ogra, fair enough [13:05] but not urgently [13:06] grab-n-drag for chrome then :) [13:06] hehe [13:06] maybe [13:06] Spec Review [13:06] er [13:06] [topic] Spec Review [13:06] New Topic: Spec Review [13:06] [link] https://wiki.ubuntu.com/MobileTeam/LucidSpecifications [13:06] LINK received: https://wiki.ubuntu.com/MobileTeam/LucidSpecifications [13:06] * ogra is still fiddling with all of his [13:06] [topic] ARM: properly support alternate images in addition to live (NCommander) [13:06] New Topic: ARM: properly support alternate images in addition to live (NCommander) [13:06] i dont think we should go through all the specs here as most stuff is still drafting [13:06] yeah [13:06] unless you have specs you really want to discuss now [13:07] If that's the case, I'm willing to skip specification review if everyone here agrees [13:07] so from my side: i reviewed a few that were set to review and dropped comments and set back to drafting [13:07] * StevenK appears [13:08] if you disagree with the comments i made (usually just minor adjustments) [13:08] let me know ;) [13:08] and we should switfch back to use LP for spec listing [13:08] using a wikipage just duplicates work [13:08] two more things: [13:08] asac, I disagree you moved a spec to Drafting over work items alone [13:08] NCommander: work items usually reflect implementation details [13:08] NCommander, the spec is not done without work items [13:09] davidm, it has work items [13:09] all we need ? [13:09] that's all mine are waiting on, filling in the work items this morning then they are ready for review [13:09] NCommander: i would like the work items to be complete before saying spec is ready to go ;) [13:10] anyway so two more things: [13:10] asac, my issue is that I can't give any more specific than a general overview of what I intend to do until i get into it specifically and know what I need to do specifically [13:10] a. if you have specs that you want to impelement for lucid that are not accepted for lucid let me know [13:10] like stacked squashfses ? [13:10] * ogra doesnt get how we missed that one [13:11] b. if you have drafted a spec that were accepted for lucid but have no assignee lets discuss that off-meeting [13:11] we need to find an assignee [13:11] ogra: yes. we can check that after the meeting [13:11] NCommander: ok thats fine. [13:11] yep [13:12] NCommander, you can make that a work item ;) [13:12] "research possibility of bleh" [13:12] NCommander: if you say you cannot split the work items up then there is not much you can do expect adding a work item like ogra said [13:12] except [13:12] asac, lets discuss this out of the meeting [13:13] sure. [13:13] I rather not run over this week [13:13] that was the idea [13:13] move on [13:13] Does anyone else have any spec-related discussion to bring up? [13:14] [topic] UNR Status [13:14] New Topic: UNR Status [13:14] drop that ? [13:14] no reason to keep it now [13:14] turn it into "image status" or something [13:14] i would think so, yes. [13:14] Right [13:14] Ok [13:14] [topic] Image status [13:14] New Topic: Image status [13:14] :-) [13:14] * ogra didnt test yet [13:15] also how do we want to handle images this time [13:15] Image builds have failed consistantly on armel due to pulse and the kernel metapackage being broken [13:15] last round we had one responsible person per arch [13:15] not sure thats possible once we have more images [13:15] which we are likely to get soon [13:15] ogra, probably best to have one person assigned to report status on a specifically SoC [13:16] indeed [13:16] Lets cross that bridge when we get to it [13:16] how do image build failures get communicated? [13:16] * ogra misses sponsoring on the agenda btw, that should have been added a month ago [13:16] e.g. are there FAIL mails send? [13:16] bugs? [13:16] ogra, I was told to remove it [13:17] NCommander: ? [13:17] asac, the responsible person needs to research the details of the failure anyway, so i personally look at the logs every day for my responsibilities [13:17] asac: http://qa.ubuntuwire.com/ftbfs/ [13:17] asac, the live image buildsystem dumps logs on people.canonical.com [13:18] NCommander: where exactly? [13:18] asac, you can also get livefs build falure emails by asking cjwatson to put you on the list (I get them for xubuntu) [13:18] NCommander, you were told to skip it for end of the release, but we decided to have a rolling topic for sponsoring [13:18] the ftbfs list is for single packages only [13:18] asac, http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ [13:18] NCommander: thx [13:18] has not much influence on image building usually [13:18] I looked at the FTBFS at pulseaudio [13:18] NCommander, hmm [13:18] Two major issues [13:18] could you mention that in a channel somewhere in the future [13:19] * ogra is just doing the same [13:19] First, -march=armv6 is forced on the commandline which breaks with compiler [13:19] but if you are doing it already, i'll stop [13:19] i think its just reverting my patch [13:19] (it tried to do armv6+thumb2, and fails miserably) [13:19] just drop it completely [13:19] ogra, that doesn't fix the issue [13:19] was only for karmic, as i stated in the changelog [13:20] well, then fix it :) [13:20] The second problem is that pulse has handwritten ARM ASM as of the latest upstreams [13:20] yes [13:20] thats why the flag was added [13:20] It uses conditional instructions in a method thats incompatible with Thumb2 [13:20] anyway, we're off topic [13:20] ogra, I'm discussing on why image fails are breaking, I don't see that as off topic [13:20] and the url above isnt the image build logs [13:21] hmm [13:21] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/lucid/ [13:21] LINK received: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/lucid/ [13:21] thats for image builds [13:21] asac, ogra er, yeah, that's livfefs-rootfs (which is needed for live CD's): http://people.canonical.com/~ubuntu-archive/cd-build-logs/ [13:21] oh, ogra beat me to it [13:21] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ is only livefs [13:21] LINK received: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ is only livefs [13:21] thx [13:22] the build system will re-use yesterdays livefs if the livefs build failed [13:22] so it doesnt have any influence on the actual image build (apart from producing a broken image) [13:22] ogra, someone needs to fix pulse by either making the compiler not build it with Thumb2, or fix the handwritten ASM. Its three instructions in a macro, so it shouldn't be too difficult [13:22] (which you can only find out through a boot/install test) [13:22] NCommander, go ahead, all yours [13:23] i have to do spec work for the rest of the week [13:23] ogra, I'm AFK after Thursday for two weeks. [13:23] I'll look at today, but if i don't crack it, someone else will have to take this up [13:23] still, pulse is off topic, lets keep that for after the meeting [13:23] NCommander: maybe there is a legacy compiler flag or something? [13:23] anysway lets move that offline [13:23] right [13:23] NCommander I can take a look tomorrow, send me the details of where you are in an email and I'll pick it up [13:23] asac, there is, haven't tested it yet. [13:23] asac: That isn't it [13:24] [topic] Sponsoring Status [13:24] New Topic: Sponsoring Status [13:24] * NCommander didn't sponsor anything during UDS, but planning to spend some time on the sponsoring queues before taking off [13:24] i guess there is a lot of merges that can be sponsored [13:25] One I get over my jetlag enough to remember my passphrase, I will [13:25] who of the team has upload rights? [13:25] but given that our main focus is specs this week we should probably skip it until we start active archive work again [13:25] asac, depends... main or universe ? [13:25] asac, I'm MOTU. ogra, and StevenK are core dev [13:25] i guess me, StevenK: ogra: NCommander (universe?) ... [13:25] ok thanks [13:25] yeah [13:26] dyfet is on his way to motu ... and JamieBennett too i guess [13:26] asac, when i do sponsoring though, I'm usually in the backport queue since I'm the only one in ubuntu-backports versus the general queue however [13:26] NCommander, just make sure its on the sponsoring list that davidm uses [13:26] so we get it counted [13:26] ogra, it won't show up due to the way backports are counted. [13:27] ogra, correct [13:27] ogra: what list is that? isnt that dholbach? [13:27] i think so [13:27] asac, yes dholbach generates the report [13:27] ok [13:28] http://people.canonical.com/~dholbach/sponsoring/ [13:28] LINK received: http://people.canonical.com/~dholbach/sponsoring/ [13:29] ok move on? [13:29] [topic] Any Other Business [13:29] New Topic: Any Other Business [13:29] we should have something about the ARM specific seed/launcher/etc on the agenda in the future imho [13:30] ogra, I added ARM Image Status to the items list [13:30] I can boil that down to ARM Status [13:30] image != apps [13:30] we have our own app list now [13:30] so we should track them [13:30] ogra, so Image Status, and ARM Status? [13:31] we're accumulating a decent backlog of arm related bugs [13:31] imae status and "ARM apps list status" i'd say [13:31] *image [13:31] many of them need triaging still, but there may be some easy ones to take care of there [13:31] https://bugs.launchpad.net/~ubuntu-armel if anyone has time to take a look, would be good to start whittling it down [13:31] plars, a ton of them was the ubuntu-iso-tester being fixed [13:31] or "ARM UNE seed status" [13:31] * NCommander finally think he got all 100 or so emails from that. [13:32] i'm not sure how much we care about jaunty bugs [13:32] NCommander: I'm looking at the actual list, not the bugmail [13:32] davidm, ?? [13:32] [LINK] https://bugs.launchpad.net/~ubuntu-armel [13:32] LINK received: https://bugs.launchpad.net/~ubuntu-armel [13:33] I moved several over yesterday, still a few that are probably arm specific and not subscribed yet. I'll work on that today after blueprints [13:33] jaunty bugs feel kind of unimportant if they are confirmed to be fixed in karmic/lucid [13:33] of course depends on the severity and what our consumers expect [13:33] right, but we have a bunch that are open in jaunty only ... should we close them ? [13:33] ogra, unless it's been 18 months we care, if they are critical and are SRU candidates. [13:33] asac, my general rule is if they/re SRU worthly, we SRU it [13:34] if not we don't care [13:34] sure. if we have a patch at hand thats a safe bet [13:34] * ogra really doubts we'll find the time to even work on them [13:34] If they aren't critical, please leave them open as "known bugs", so that potential jaunty users can see the issues ahead of them. [13:34] right [13:35] or set them to won't fix if they are not SRU candidates? [13:35] either of that works for me [13:35] i'd just like to see the list be smaller and show the ones we can actually put time in [13:36] ogra: that should be handled through "Importance" [13:36] keeping all the jaunty bugs we wont fix seems to just crowd the list [13:36] High or higher -> we care [13:36] medium or below -> we usually dont care -> either open or set to won't fix teaching user about the SRU policy etc. [13:36] Um, please don't. "Won't Fix" implies there is a reason they should not be fixed, as opposed to just that they aren't going to be fixed because nobody got around to it yet. [13:36] Just leave them as open tasks with nobody assigned, and if someone wants to do it, they can. [13:37] persia: i think won't fix is used to invalidate targetted bugs [13:37] buy the release team [13:37] dont think its completely off ... if you report a bug you will still see them as duplicate suggestions [13:37] s/buy/by/ [13:37] asac: That and also to indicate that something will never be done (some gnome-desktop type bugs) [13:38] persia, the jaunty task can be set to Won't Fix [13:38] right [13:38] But for a lot of packages, an SRU patch does apply with minimal work to jaunty [13:38] NCommander: I'm asking that it not be *unless* there is some reason it should not be fixed. [13:38] persia: so we are just talking about jaunty task ... not the main task [13:38] (if the issue existed in karmic) [13:38] Just because you're too lazy/busy to do it doesn't mean someone else won't do it. [13:38] take bug 428263 [13:38] Bug 428263 on http://launchpad.net/bugs/428263 is private [13:38] thats unfixable in jaunty without backporting the whole of mono [13:38] if the bug is fixed in lucid and we decide we dont fix it in jaunty i dont see why we shouldnt set the jaunty task to wont fix [13:39] hmm, bad example :P [13:39] like you confirmed, its used by release team to deny targeted bugs [13:39] ogra, of course, but there are other bugs which the same patch fixes it across multiple versions. [13:39] there are also several gcc/toolchain related bugs that are automatically fixed with a newer toolchain [13:39] For that example, I agree "won't Fix" is the right answer, because it's just too invasive to fix it. [13:40] The difference being "bug which can't be fixed sensibly" vs. "bug which nobody got around to fixing, and nobody currently plans to fix". [13:40] and we surely wont backport toolchains [13:40] persia: bugs with medium or below prio are "too invasive" by definition for an SRU [13:41] i suggested that high or critical bugs stay open in any case [13:41] asac: Interesting argument. You're suggesting that any old task which isn't approved for SRU should inherently be "Won't Fix"? [13:41] so if it is disqualified as a target for SRU, then it should be won't fix, if it's a possibility (or even if there is doubt about whether or not it could be SRU) it should be kept open [13:41] persia: having an open task for jaunty usually means: "approved for SRU" .. unless its set to wont fix [13:42] remember only folks with bugcontrol can approve nominations [13:42] so accepting a nomination usually means: yes, this is a bug that should get fixed in the task (aka SRU) [13:42] OK. That makes sense to me. It's stuff which won't get fixed no matter how many people volunteer. [13:42] asac: you need more than that actually, I think you have to be in drivers [13:43] It's somewhere between those, but it's messy. Let's ignore that for now. [13:43] persia: more or less yes. there might be exceptions if there is a patch at hand we can take as ride along. but we also dont want to encourage community folks to put their time in such bugs [13:43] so seting to wont fix would be a reasonable step for medium or below targetted bugs imo [13:44] anyway if we cannot get consent here lets discuss after meeting [13:44] Final topic I have [13:44] asac: I'm presuming we're discussing bugs already fixed in newer releases (where even a patch won't make it SRU-worthy). [13:44] I agree patches are useful, but they belong to current-dev-release unless it's an SRU bug. [13:44] Right. [13:44] I'm not going to be here for two weeks after this meeting. persia already agreed to run the meeting for the first week of Decemember [13:44] *December [13:45] persia: right that was what ogra ment afaict. bugs that are jaunty only but are not SRU candidates [13:45] I'm looking for a volunteer for next week [13:45] * persia suggests using dates, to avoid confusion [13:45] 1 December needs a volunteer [13:45] 8 December is covered === ogra_ is now known as ogra [13:45] grmbl [13:46] No volunteers? [13:46] I can take that if noone else wants to do it ;) [13:46] asac, seems you get it by default [13:46] sorry, line dropped ... [13:46] NCommander: where do you put the (now updated) "default" agenda items? [13:46] NCommander: right ;) [13:46] asac, I just edit the wiki page to reflect what we actually covered. [13:46] NCommander: link? [13:47] asac, https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091124#preview [13:47] I usually post it at the start of the meeting. [13:47] (sorry, still ned to catch all resources ;)) [13:47] Sponsoring Statusemsv ? [13:47] NCommander: do we have a template for that? [13:47] asac, no [13:47] we copy over last weeks and edit usually [13:48] yeah. template is similar easy ;) [13:48] but ok [13:48] or NCommander does as our -meeting chair [13:48] asac, I'll create the pages in advance for you [13:48] you just need to filli n the blanks for next week [13:48] NCommander: rock ;) ... do you usually send out reminder mails? [13:48] yes [13:48] asac, yes, to ubuntu-mobile [13:48] to the mobile list [13:48] Minutes also go to the same place [13:48] (as I discovered during UDS) [13:49] right, thats new [13:49] ogra, well, its more remembered versus new :-) [13:49] you didnt do that in the past [13:49] new for *you* :) [13:49] ok thanks [13:49] ogra, fair enough [13:50] anything else to cover? [13:50] if not, I'm going to close the meeting [13:50] #endmeeting [13:50] Meeting finished at 07:50. [13:50] thanks all! [13:51] thanks [13:51] * GrueMaster returns to sleep. === porthose__ is now known as padpuck === padpuck is now known as porthose [15:00] * kees looks around for DMB meeting [15:01] * tseliot is waiting for the same reason [15:01] * porthose is waiting for the same reason [15:02] kees: who's driving? [15:02] Keybuk: not sure; the only agenda I can find is referenced from the TB agenda. [15:02] DMB: compiz-related upload rights for Travis Watkins (approved by MC) [15:02] DMB: core-dev reactivation for Daniel Chen [15:02] DMB: core-dev application for Marc Deslauriers (approved by MC) [15:02] DMB: Apply upload rights: Charlie Smotherman (porthose) [15:02] though I don't feel that two is in any way quorate [15:03] 'zactly [15:03] hello [15:04] up to 3! :) heya pitti [15:04] I think we can go with three [15:04] sorry for being late [15:04] any more is just greedy [15:04] heh [15:04] * Keybuk recalls pitti said he'd chair [15:04] I am here, but I didn't know this meeting was happening [15:04] #startmeeting [15:04] Meeting started at 09:04. The chair is pitti. [15:04] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:05] mdz: well, _if_ you'd turned up at the last TB meeting ... [15:05] mdz: we agreed to it on last TB, and I sent it to u-d-a@ [15:05] it's not on my calendar, the platform calendar, the fridge calendar or any other that I look at [15:05] pitti, bah, so I'm supposed to keep up with mailing lists during the second half of UDS? ;-) [15:05] mdz: that sounded like volunteering an action to me [15:05] right, sorry about that; will poke people to add to fridge next time [15:06] is this meant to be a recurring time slot? [15:06] if so, it's not very good for me [15:06] yes, afaik [15:06] we didn't decide on that really [15:06] just that we need one to process the current backlog === robbiew_ is now known as robbiew [15:06] it makes sense to have a regular slot [15:06] so that if there is agenda, we cover it [15:07] if there's nobody waiting, we simply don't hold the meeting [15:07] [TOPIC] DMB meeting time [15:07] New Topic: DMB meeting time [15:07] is there going to be another meeting on November 26? [15:07] mdz: it's the same time slot as TB; should we have a different one more convenient for you then? [15:07] I would prefer it not be any earlier, but I'm otherwise generally open. [15:08] tseliot: certainly not for DMB? [15:09] for me, I'm also fine with the current slot; bit earlier/later WFM [15:10] mdz: there's nothing on your calendar at this time? [15:10] pitti: ah, right, that will be for MC [15:11] pitti: I suggest we move on [15:11] *nod* [15:11] let's keep the current time for now [15:11] [ACTION] pitti to mail DMB about meeting time discussion [15:11] ACTION received: pitti to mail DMB about meeting time discussion [15:11] on the simple basis that everyone else is here :p [15:11]