[05:01] <Agent007> Ubuntu is pretty unworthy to be on my desktop
[10:02]  * persia wonders if it is one of those days
[10:10] <nigelb> persia: wasn't it supposed to be last week?
[10:13] <persia> Yeah, but it wasn't, which makes me wonder if it's this week.  I think it isn't.
[10:14] <nigelb> I think I haven't seen an Asia meeting in Nov at all
[10:15] <persia> On the bright side, I don't think you've missed any :)
[10:21] <nigelb> persia: lol
[10:57]  * lifeless is epically confused
[11:01] <nigelb> persia: heh, you should just start a meeting and action youself to remind the rest of the board members ;)
[11:02] <nigelb> @now
[11:02] <persia> Too late.  I'll do that next week if there isn't a meeting.
[11:03] <nigelb> lifeless: 10 am.  London probably isn't UTC
[11:03] <nigelb> No, it isn't.
[11:04] <lifeless> too late is a local phenomena
[11:04] <nigelb> heh
[11:29] <RawChid> #ubuntu-team
[12:59] <NCommander> #startmeeting
[12:59] <MootBot> Meeting started at 06:59. The chair is NCommander.
[12:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:59] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101130
[12:59] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20101130
[12:59] <ogra_ac> bah
[12:59] <NCommander> just for the record, who's here?
[12:59] <ogra_ac> youre to early
[13:00]  * janimo is here
[13:00] <ogra_ac> adjust your clock !
[13:00] <davidm> hello
[13:00] <ogra_ac> that link doesnt match the one from the announcement :P
[13:00] <NCommander> morning davidm
[13:00] <NCommander> ogra_ac: so I made a slight mistake
[13:01] <NCommander> [topic] Action Item Review
[13:01] <MootBot> New Topic:  Action Item Review
[13:01] <NCommander> [topic] persia to handle namespace renaming
[13:01] <MootBot> New Topic:  persia to handle namespace renaming
[13:01]  * NCommander pokes persia 
[13:01] <persia> Ugh.  Editing the wrong page :(
[13:01]  * rsalveti wonders when the announcement will bring the correct link hehe
[13:02] <NCommander> rsalveti: I put a redirect on the link I sent by accident
[13:03] <rsalveti> NCommander: ok, that wasn't there when I tried
[13:03] <persia> Carry it over.  It's in-process (except at the wrong place :/ )
[13:03] <NCommander> [topic] persia and NCommander to work out new meeting announcement text
[13:03] <MootBot> New Topic:  persia and NCommander to work out new meeting announcement text
[13:04] <NCommander> s/Mobile/ARM/g was really it
[13:04] <persia> I think that was lost due to "Thanksgiving", or at least we didn't seem to be online at the same time much.
[13:04] <persia> No, we have to make it better :)
[13:04] <NCommander> so c/o
[13:04] <NCommander> [topic] persia to make the bugsquad create a bug overview page for ubuntu-armel
[13:04] <MootBot> New Topic:  persia to make the bugsquad create a bug overview page for ubuntu-armel
[13:05] <persia> Didn't find the person I wanted much (little overlap again).  I expect to find them in the next few hours :)
[13:05] <NCommander> [topic] Special Items
[13:05] <MootBot> New Topic:  Special Items
[13:05] <NCommander> [topic new meeting time
[13:05] <NCommander> [topic] new meeting time
[13:05] <MootBot> New Topic:  new meeting time
[13:05] <ogra_ac> NCommander, it was more than /Mobile/ARM
[13:06] <ogra_ac> (sigh)
[13:06]  * ogra_ac wishes you wouldnt rush so fast
[13:06] <persia> So, I talked to lots of folk, and 15:00 Thursday seemed the least inconvenient.
[13:07] <persia> Well, "lots" is really only about 10 people, but still :)
[13:07] <ogra_ac> persia, for the bugsquad page, just ping bdmurray
[13:07] <NCommander> so 7 PST, 9 CST, 10 EST, and something over in Europe
[13:07] <persia> Is anyone here now that wouldn't be able to make it then?
[13:07] <persia> ogra, I know, but Thanksgiving :)
[13:07] <ogra_ac> it took him 30sec to change it to canonical-arm for us
[13:07] <ogra_ac> ok
[13:07] <persia> Yeah, just need overlap.  I expect I'll catch him beginning of his day today.
[13:08] <rsalveti> persia: 15 utc?
[13:08] <ogra_ac> NCommander, UTC times please
[13:08] <persia> rsalveti, Yes.
[13:08] <rsalveti> I'm fine
[13:08] <janimo> me too
[13:08]  * ogra_ac too
[13:08]  * NCommander will be with coffee
[13:09] <persia> OK, so it will move to then, starting from 9th December.
[13:09] <GrueMaster> coffee not working at 5am PST.  Sorry.
[13:09] <persia> By the way, what's the team membership policy?
[13:09] <NCommander> [action] NCommander to annouce new time with Dec 9th meeting
[13:09] <MootBot> ACTION received:  NCommander to annouce new time with Dec 9th meeting
[13:09] <persia> Just ask an admin?
[13:09] <ogra_ac> persia, which team ?
[13:09] <NCommander> persia: requires a vote
[13:09] <NCommander> or well
[13:09] <NCommander> for the mobile team it did
[13:10] <NCommander> ubuntu-armel I think is just add yourself
[13:10] <ogra_ac> which team are we talking about ?
[13:10] <persia> ubuntu-armel
[13:10] <ogra_ac> no, its moderated
[13:10] <persia> Yeah, what's the policy?
[13:10] <ogra_ac> just as an admin, yeah
[13:10] <persia> That's what I thought: just wanted to verify.
[13:10] <ogra_ac> do we want more admins ?
[13:11]  * ogra_ac will happily add another
[13:11]  * persia wants *NOT* to be an admin :)
[13:11]  * NCommander could do it as I run the meeting and could add people who ask
[13:11] <ogra_ac> well, just to have a fallback
[13:12] <ogra_ac> NCommander, ok, i'll add you after the meeting
[13:12] <NCommander> thanks
[13:12] <NCommander> [topic] Standing Items
[13:12] <MootBot> New Topic:  Standing Items
[13:12] <NCommander> [link] http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel.html
[13:12] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel.html
[13:12] <NCommander> [link] http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel-natty-alpha-1.html
[13:12] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel-natty-alpha-1.html
[13:14] <ogra_ac> please move your WIs to A2
[13:14] <ogra_ac> if you dont plan to get to them today
[13:14]  * NCommander seconds ogra_ac's comments
[13:14] <ogra_ac> we look really really bad
[13:14] <davidm> Mine are done or moved :-)
[13:14] <NCommander> BTW, ogra_ac http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel-natty-alpha-2.html
[13:14] <ogra_ac> GrueMaster, still has two A1 items
[13:14] <NCommander> can you get THAT fixed
[13:15] <GrueMaster> If they need to be done today, I'll move mine to A2.  Was planning on pushing out list this week.
[13:15] <ogra_ac> NCommander, ask persia ;)
[13:16] <ogra_ac> NCommander, he maintains that page
[13:16] <NCommander> anyway
[13:16] <ogra_ac> i care for canonical-arm only (and said so before we had the second page=
[13:16] <NCommander> can I move on from burndown charts?
[13:16] <ogra_ac> erm
[13:16] <ogra_ac> where are the canonical-armel charts in your paste?
[13:17]  * ogra_ac sighs and goes to the other page
[13:17] <ogra_ac> http://people.canonical.com/~pitti/workitems/natty/canonical-arm.html
[13:17] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-arm.html
[13:17] <ogra_ac> we're way over trendline here
[13:18] <ogra_ac> so please work on your itmes :)
[13:18] <NCommander> anyway
[13:18] <NCommander> [link] http://qa.ubuntu.com/reports/team-assigned/canonical-arm-assigned-bug-tasks.html
[13:18] <MootBot> LINK received:  http://qa.ubuntu.com/reports/team-assigned/canonical-arm-assigned-bug-tasks.html
[13:19] <NCommander> I've made some work on mono and have some test cases that crash wonderfully
[13:19] <NCommander> Will work on it some more, but its only a medium on my TODO
[13:19] <NCommander> flash-kernel will get fixed as soon as I rebuild the XM's SD
[13:19] <janimo> NCommander: I can try to help with that if you brief me in
[13:20] <janimo> mono I mean
[13:20] <NCommander> janimo: needs hardware unfortunately. As soon sa you have it, I'd be glad to have assistance :-)
[13:20] <janimo> ah ok
[13:20] <janimo> so far I am poking around kakadu
[13:20] <GrueMaster> persia: There are a lot of ancient bugs assigned to you.  Can you update them and close them so we can get them off the list?
[13:21] <NCommander> janimo: you can't run X apps on kakadu which is the original basis of the bug, and our litimus test on if we fixed it so to speak in addition to the mono test suite. If you want to grab mono and build from source and run the test suite and play with it, that should work on kakadu
[13:21] <rsalveti> davidm: did you send the beagle to janimo?
[13:21] <rsalveti> if so, janimo will probably get it in 2, 3 days
[13:21] <janimo> NCommander: which is the LP bug you are chasing?
[13:21] <NCommander> janimo: its the banshee bug which is actually mono
[13:22] <janimo> NCommander: I was under the impression that mono or related stuff FTBFS , not a runtime crash
[13:22] <janimo> ah ok
[13:22] <NCommander> janimo: runtime crash annoying :-/
[13:22] <janimo> I see
[13:23] <NCommander> mono under ARM has always been a bit twichy
[13:23] <NCommander> anyway, can I move on?
[13:23] <janimo> apparently did not work on maverick already
[13:23] <janimo> sure
[13:23] <ogra_ac> move
[13:23] <NCommander> [topic] Kernel Status (cooloney)
[13:23] <MootBot> New Topic:  Kernel Status (cooloney)
[13:23] <ogra_ac> so we had some tests of linaros omap3 kernel i belive
[13:23] <ogra_ac> :)
[13:23] <ogra_ac> cooloney isnt here
[13:24] <ogra_ac> so i'll summarize
[13:24] <ogra_ac> it seems to work on rootstock images
[13:24] <GrueMaster> I just saw the note this morning to test it on XM.  Will try to get to it today.
[13:24] <ogra_ac> rsalveti, offered to test on XM
[13:24] <rsalveti> sure, going on this today
[13:24] <ogra_ac> so we see if jasper still does the right thing
[13:24] <ogra_ac> once thats done a config comparison has to happen
[13:25] <rsalveti> I believe the only remaining thing for cooloney is to check and compare the config
[13:25] <ogra_ac> if thats ok for us as well, the ball is on apw's table
[13:25] <ogra_ac> to commit (or not) to SRU and security uploads
[13:25] <rsalveti> yeah
[13:25] <ogra_ac> s/apw/kernel-team/
[13:26] <rsalveti> so we'll test, cooloney will check the config and the kernel team will give the proper ack
[13:26] <rsalveti> then we can continue
[13:26] <rsalveti> no more for kernel I believe
[13:26] <ogra_ac> right
[13:27] <ogra_ac> then we need MIRs etc
[13:27] <ogra_ac> or one MIR
[13:27] <rsalveti> yeah
[13:27] <davidm> rsalveti, beagle will go out today, was delayed
[13:27] <rsalveti> cool :-)
[13:28] <rsalveti> so I believe janimo will have a new toy to play even during weekend if he wants :-)
[13:28] <janimo> good :)
[13:28] <ogra_ac> i cant judge the omap4 kernel
[13:28] <ogra_ac> GrueMaster, did it work on the images from the 19th ?
[13:29] <GrueMaster> No.  I have a note in my QA update.
[13:29] <ogra_ac> k
[13:29] <ogra_ac> so lets move on
[13:29] <ogra_ac> NCommander,
[13:29] <NCommander> [topic] QA Status (GrueMaster)
[13:29] <MootBot> New Topic:  QA Status (GrueMaster)
[13:29] <GrueMaster> Currently seeing issues with Maverick kernel updates on panda.  Base image works fine.  Once kernel is updated, no monitor output is visible.
[13:30] <GrueMaster> Last natty image had a kernel segfault during second boot, before X would launch.  Investigating today to see what broke before A1 images appear.
[13:30] <GrueMaster> Will post a list for checkbox test tweaks this week, barring major image testing issues and sleep depravating meetings.
[13:30]  * ogra_ac has all kernel updates in maverick on his panda
[13:30] <GrueMaster> These are the issues I am currently dealing with.
[13:30] <ogra_ac> and has still fine display output
[13:30]  * rsalveti too
[13:30] <rsalveti> probably an issue with the new monitor GrueMaster got
[13:30] <ogra_ac> yeah
[13:30] <ogra_ac> dont buy dell ;)
[13:31] <ogra_ac> we know there are issues with their EDID
[13:31] <GrueMaster> On the panda, yesterday I started with a fresh image and only updated the kernel.  After rebooting, no video.  This was on my old monitor I used for testing last cycle.
[13:31] <ogra_ac> ah
[13:31] <ogra_ac> intresting
[13:31] <rsalveti> that's weird, works fine for me
[13:31] <GrueMaster> BTW:  Dell monitor worked fine on released image.
[13:31] <ogra_ac> did you modify boot.scr in any way ?
[13:31] <rsalveti> and there wasn't any change that affect the video
[13:31] <ogra_ac> yeah
[13:31] <GrueMaster> Not until I started seeing issues.
[13:32] <ogra_ac> works fine here too wiht a default image upgraded across all -updates/-security kernels
[13:32] <rsalveti> anyway, needs further debugging
[13:32] <ogra_ac> right
[13:32] <ogra_ac> anything else for QA ?
[13:32] <GrueMaster> Yes, I plan on doing more testing today.  I was distracted yesterday with other issues.
[13:33] <GrueMaster> None other than what I posted above.
[13:33] <ogra_ac> NCommander,
[13:33] <NCommander> [topic] ARM Porting/FTBFS status (NCommander)
[13:33] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander)
[13:33] <ogra_ac> should have janimo in the brackets too ;)
[13:33] <NCommander> Applied a patch today to work around KDE being FTBFS so libproxy woul dbuild getting us closer to A1 images
[13:33] <NCommander> transmission was deseeded on ARM for a similar reason
[13:34]  * ogra_ac gave back a good bunch of packages yesterday
[13:34] <NCommander> both changes will be reverted past A1
[13:34] <ogra_ac> most of tehm survived the build
[13:34] <NCommander> looks like we're on track for A1 images. A team first I might add
[13:34] <ogra_ac> well, we'll see (more in the image section=
[13:34] <rsalveti> NCommander: I believe we just need a bug to revert this after a1
[13:34] <ogra_ac> )
[13:34] <rsalveti> as lool pointed out at the bug
[13:35] <ogra_ac> yeah, lool asked for one
[13:35] <ogra_ac> and it makes sense so we dont forget
[13:35] <NCommander> rsalveti: I'm just going to reopen the bug that we used to revert
[13:35] <rsalveti> yeah
[13:35] <ogra_ac> (though i guess ScottK would complain anyway) ;)
[13:35] <ogra_ac> that u! doesnt work on kubuntu arm
[13:35] <ogra_ac> *U1
[13:35] <ScottK> No  I consider that a feature.
[13:36] <ogra_ac> lol
[13:36] <rsalveti> :-)
[13:36] <ogra_ac> ScottK, what if i switched to kubuntu now ?
[13:36] <rsalveti> currently? boom
[13:36] <ogra_ac> i would complain loudly that i cant use my U1 purchased music
[13:36] <ogra_ac> :)
[13:37] <ScottK> You'd want a different architecture thanks to gcc "improvements"
[13:37] <NCommander> ogra_ac: at least you can use the U1 music store
[13:37] <ogra_ac> (well, not using natty in production indeed)
[13:37] <NCommander> Kubuntu users can't without firing up GNOME last time I tried
[13:37] <ScottK> The regular U1 client works fine as I understand it.
[13:37] <NCommander> but this is completely off-topic
[13:37] <ogra_ac> hmm, right
[13:37] <ogra_ac> anyway, seems thats it for ftbfs
[13:38] <NCommander> [topic] ARM Image Status (ogra, NCommander)
[13:38] <MootBot> New Topic:  ARM Image Status (ogra, NCommander)
[13:38] <ogra_ac> bad
[13:38] <ogra_ac> broken
[13:38] <ogra_ac> etc etc
[13:38] <rsalveti> :-)
[13:38] <ogra_ac> NCommander, and i sorted most of the obvious blockers
[13:38] <ogra_ac> but we dont know if there are subsequent ones yet
[13:39] <ogra_ac> i will fire off a testbuild after the meeting
[13:39] <ogra_ac> so we can see
[13:39] <rsalveti> oh, ok
[13:39] <ogra_ac> should be usable for A1 i hope
[13:39] <ogra_ac> but there are more things omn the ftbfs list
[13:39] <rsalveti> what is the fix date limit, today?
[13:40] <ogra_ac> rsalveti, thu is A1 release date
[13:40] <ogra_ac> as long as we have booting images by then its fine
[13:40] <rsalveti> cool
[13:40] <ogra_ac> A1 criteria is "bootable"
[13:40] <ogra_ac> everythig else is nice to have
[13:40] <rsalveti> got it
[13:40] <ogra_ac> oh
[13:40] <ogra_ac> and we obviously dont build omap3 images until the kernel is there
[13:41] <NCommander> I think that's everything
[13:41] <NCommander> can we move on?
[13:41] <ogra_ac> since the old one is gone
[13:41] <ogra_ac> move
[13:41] <rsalveti> sure, np
[13:41] <NCommander> [topic] Any Other Business
[13:41] <MootBot> New Topic:  Any Other Business
[13:41]  * ogra_ac has something ...
[13:41] <NCommander> I'd like to tka ea moment to introduce james_w
[13:41] <NCommander> er
[13:41] <NCommander> damn it
[13:41] <ogra_ac> lol
[13:41] <ogra_ac> hello james_w
[13:41] <ogra_ac> :P
[13:41] <rsalveti> another new team member?
[13:41] <NCommander> janimo:
[13:41] <ogra_ac> NCommander, nice that you introduce him
[13:41] <janimo> hello all
[13:42] <davidm> janimo, welcome
[13:42] <ogra_ac> hey janimo, welcome to the team
[13:42] <rsalveti> yeah :-)
[13:42] <rsalveti> hopefully you'll like it
[13:42] <janimo> thanks. Any other tasks besides FTBFS that I should start looking into?
[13:42] <janimo> How are work items assgined?
[13:42] <janimo> I hope so too :)
[13:42] <NCommander> janimo: the meaning of life, the universe, and everything?
[13:42] <ogra_ac> janimo, please look through http://people.canonical.com/~pitti/workitems/natty/canonical-arm.html and see if you like to take over any WIs that intrest you
[13:42] <rsalveti> yeah, better
[13:43] <ogra_ac> and let us know so we can assign them to you
[13:43] <janimo> I see quite a few that are interesting
[13:43] <rsalveti> janimo: what you generally like to work with?
[13:43] <janimo> but not sure how much involved other memebers are already in them
[13:43] <ogra_ac> janimo, so best is to contact the asignee and have him assign items to you
[13:43] <janimo> rsalveti: once I have hardware as well, things which are close to hw are fine
[13:43] <rsalveti> see what you'd like to help with, poke the original target member and see
[13:43] <janimo> I see some of the WIs are assigned to members outside the ARM team
[13:44] <rsalveti> janimo: cool
[13:44] <janimo> such as 'make lightspark build on ARM'
[13:44] <ogra_ac> feel free to take that over from stgraber
[13:44] <janimo> ok
[13:44] <ogra_ac> i worked on it with him already
[13:45] <ogra_ac> and the prob is that lightspark uses a lot of intel SSE assembler
[13:45] <ogra_ac> that needs to be rewritten completely for arm
[13:45] <janimo> yep, just read that
[13:45] <janimo> so not just a pacvkaging task
[13:45] <ogra_ac> which neither of stgraber or me will have time to do
[13:45] <ogra_ac> i have packaging fixes
[13:45] <janimo> I can look at that even if it sounds quite a large task
[13:45] <ogra_ac> i can get it build up to a point where it gets to the asm stuff
[13:46] <ogra_ac> but indeed not beyond
[13:46] <janimo> what I am not yet sue about how ARM/DX/linaro and other upstream teams agree on whose WI something is but will get used to :)
[13:46] <rsalveti> janimo: generally over uds
[13:46] <janimo> but any of you feel free to ask/assign me to help out some WI's which you are not yet started with or would rather pass on
[13:46] <ogra_ac> http://people.canonical.com/~pitti/workitems/natty/canonical-arm.html has all WIs we are intrested in from a canonical-arm POV
[13:46] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-arm.html has all WIs we are intrested in from a canonical-arm POV
[13:46] <rsalveti> during the discussion of the bp
[13:47] <ogra_ac> the wider community view should be on http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel.html
[13:47] <janimo> but canonical-arm is the priority?
[13:47] <ogra_ac> NCommander, can you please remove the *pitti from the links in the wiki ?
[13:47] <rsalveti> janimo: also starts following linaro
[13:47] <ogra_ac> janimo, for canonical work stuff, yeah
[13:47] <NCommander> ogra_ac: k
[13:48] <ogra_ac> NCommander, that has to be ~platform
[13:48] <NCommander> [action] NCommander to fix workitem links
[13:48] <MootBot> ACTION received:  NCommander to fix workitem links
[13:48] <davidm> janimo, yes for canonical work stuff
[13:48] <rsalveti> join #linaro, linaro's m-l and etc, we generally have overlap with them
[13:48] <ogra_ac> they have packages they care about which we usually only rarely touch (i.e. toolchain)
[13:48] <ogra_ac> and they have different requirements
[13:49] <ogra_ac> so talking to them usually makes sense
[13:49] <NCommander> ogra_ac: I think we should take this to another channel TBH
[13:49] <NCommander> I'm ready to close out the meeting
[13:49]  * ogra_ac still has an item :P
[13:49] <janimo> ok. Especially since some FTBFS have toolchain implications
[13:49] <rsalveti> janimo: yeah
[13:49] <rsalveti> ogra: move on
[13:49] <ogra_ac> right, talk to linaro, they have good toolchain experts
[13:49] <ogra_ac> well, i'm on vacation from monday on til end of the year
[13:50] <ogra_ac> having to burn all my vacation days
[13:50] <ogra_ac> i will likely still be online on IRC here and there
[13:50] <ogra_ac> but dont ask me about work :P
[13:50] <rsalveti> ogra_ac: cool, enjoy :-)
[13:50] <rsalveti> found anywhere to travel already?
[13:50] <GrueMaster> we never do.  :P
[13:50] <janimo> ogra_ac: have a relaxing time!
[13:51] <ogra_ac> i only need to collect some miles, will likely just do a one day flight to some far but cheap place
[13:51] <janimo> iceland?
[13:51] <ogra_ac> beyond that i will care for my house
[13:51] <ogra_ac> janimo, to close sadly
[13:51]  * NCommander is glad to know he's not the only one flying on occession for status :-)
[13:51] <ogra_ac> i considered it ;)
[13:51] <NCommander> The joys of mileage running
[13:51] <janimo> ogra_ac: not if you go via mumbai
[13:51] <ogra_ac> NCommander, i wont do that twice in my life
[13:51] <ogra_ac> janimo, but then it gets to expensive ;)
[13:52] <ogra_ac> mumbai was also on the list btw ;)
[13:52] <janimo> moscow?
[13:52] <ogra_ac> but anyway, lets not get to much off topic
[13:52] <ogra_ac> to close again ;)
[13:52] <rsalveti> :-)
[13:52] <janimo> ok
[13:52] <rsalveti> any other topics?
[13:52] <ogra_ac> (and to cold)
[13:52]  * ogra_ac has nothing
[13:52] <janimo> so I'll probably start asking team members if they want to pass me some WIs
[13:52] <ogra_ac> yeah, do that
[13:52] <janimo> so I can do some more focused work for alpha2
[13:53] <ogra_ac> we didnt really have much for A1
[13:53] <janimo> but you can also start telling me about WIs you could use help with
[13:53] <ogra_ac> indeed
[13:53] <NCommander> Ok, I'm going to close the meetin gout just caue we're going offtopic
[13:54] <NCommander> janimo: ogra_ac: lets move this to ubuntu-arm
[13:54] <NCommander> Closing in 3
[13:54] <NCommander> 2
[13:54] <NCommander> 1
[13:54] <NCommander> #endmeeting
[13:54] <MootBot> Meeting finished at 07:54.
[14:59] <mdz> cjwatson, kees, Keybuk, pitti, sabdfl: ping
[14:59] <mdz> #startmeeting
[14:59] <MootBot> Meeting started at 08:59. The chair is mdz.
[14:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:00] <pitti> hello
[15:00] <mdz> [topic] Action review
[15:00] <MootBot> New Topic:  Action review
[15:00] <mdz> [link] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000784.html
[15:00] <MootBot> LINK received:  https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000784.html
[15:01] <mdz> I missed the previous meeting, so please correct me if I've missed anything
[15:01] <pitti> KDE microversion SRU docs has happened
[15:01] <mdz> it looks like there were no actions per se, though there were a couple of things which should be back on the agenda for this meeting
[15:02] <mdz> couchdb & U1 on 10.04
[15:02] <pitti> right, the couchdb SRU and post-maverick updates
[15:02] <mdz> pitti: what is the status of the ARB exception proposal?
[15:02] <pitti> it was discussed a bit after the last meeting, but I didn't see much news there
[15:02] <mdz> ok
[15:02] <pitti> it sounded like 90% of an agreement
[15:02] <wendar> we ran out of time
[15:02] <mdz> is Chipaca around?
[15:03] <pitti> hey wendar
[15:03] <wendar> hi pitti
[15:03] <mdz> hi Chipaca
[15:03] <Chipaca> hi mdz
[15:03] <wendar> I've got a reply in the moderation queue again, if someone could give it a push before we get to that point in the agenda
[15:03] <mdz> [link] https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:03] <MootBot> LINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:04] <mdz> wendar: there are no messages in the moderation queue for technical-board
[15:04] <pitti> wendar: ah, your reply just hit the list
[15:04] <mdz> [topic] couchdb lucid backport SRU - John Lenton
[15:04] <MootBot> New Topic:  couchdb lucid backport SRU - John Lenton
[15:04] <mdz> so I missed the previous meeting, but have talked with Chipaca a little bit out of band
[15:05] <pitti> that was also discussed on the TB ML
[15:05] <pitti> with some updates from yesterday/today
[15:05] <mdz> according to the minutes, the TB proposed an alternative solution and asked the U1 team to evaluate it
[15:05] <mdz> ah, I hadn't read the latest
[15:05] <mdz> pitti: would you like to guide the discussion?
[15:05] <pitti> the alternative solution was proposed to ship a separate couchdb-1.0 package in lucid-updates
[15:06] <pitti> mdz: yes, can do
[15:06] <pitti> hello Chipaca
[15:06] <Chipaca> I need to bbiab, this battery is running out and i've got the wrong charger. give me a minute please.
[15:06] <mdz> [link] https://lists.ubuntu.com/archives/technical-board/2010-November/000590.html
[15:06] <MootBot> LINK received:  https://lists.ubuntu.com/archives/technical-board/2010-November/000590.html
[15:06] <mdz> is the latest from Chipaca on the mailing list
[15:07] <pitti> right, and https://lists.ubuntu.com/archives/technical-board/2010-November/000592.html my latest reply
[15:09] <mdz> so Chipaca is saying that it's not feasible, from the sound of it
[15:09] <pitti> I'm interested in why
[15:09] <Chipaca> hi, back
[15:09] <mdz>  * while we can introduce a couchdb-1.0-bin package into 10.04 to
[15:09] <mdz>    address this issue, we can't really make it co-exist on the same
[15:09] <mdz>    machine wiht a 0.10 couchdb-bin, so it would have to conflict with
[15:09] <mdz>    it; additionally, we'd have to get a SRU for a client package in
[15:09] <mdz>    10.04 (either desktopcouch or ubuntuone-client would work) so that
[15:09] <mdz>    the 1.0 package gets pulled in, and an additional SRU for 10.10 to
[15:09] <mdz>    get the dependency fixed.
[15:10] <pitti> when we update the main couchdb package, I'd frankly feel overwhelmed, and that we deliberately break API and stability (and thus working setups) in favor of enabling features
[15:10] <mdz> pitti, I believe you questioned the co-existence point
[15:10] <pitti> right, I'm curious why it wouldn't work
[15:10] <mdz> I'm inferring from Chipaca's tone that perhaps it just seems like too much work
[15:11] <Chipaca> it could be made to work, in the "it's just software" sense. We can't make it work in that it would be a big change, as we'd have to add code to let desktopcouch start the right version of couch
[15:11] <pitti> and AFAIK it doesn't auto-migrate existing databases over to the 1.0 format, right?
[15:12] <Chipaca> couchdb auto-migrates, yes
[15:12] <Chipaca> the way we're shipping the system couchdb explicitly avoids the auto-migration
[15:12] <Chipaca> by adding the version number to the path to the database
[15:13] <pitti> so this would help making both co-installable
[15:14] <Chipaca> what does co-installation try to fix?
[15:14] <mdz> Chipaca: it seems like decoupling desktopcouch from the system-wide couchdb might be a good long-term move
[15:15] <mdz> it would enable you to update "your" couchdb without risking breakage in other couchdb applications
[15:15] <pitti> Chipaca: not breaking the database API for existing insallations
[15:16] <mdz> Chipaca: otherwise we will surely face exactly this same choice the next time you want to update
[15:16] <mdz> do you need help getting the packaging right?
[15:17] <mdz> or do you feel this is not the best solution?
[15:17] <Chipaca> the problem is not the packaging, which yes I will probably need help with because of resources, the problem is afaik starting and connecting to the "right" couchdb from desktopcouch
[15:17] <pitti> if we can auto-migrate user databases, then we could switch desktopcouch to use 1.0?
[15:18] <pitti> as far as I remember, the desktopcouch API wouldn't change
[15:19] <Chipaca> right, we'd update the desktopcouch package to depend on 1.0, and then we'd have to make desktopcouch start 1.0
[15:19] <mdz> Chipaca: I guess I don't understand why that's hard
[15:20] <pitti> and don't we need to do that either way?
[15:20] <pitti> adapting desktopcouch to start 1.0, I mean
[15:20] <mdz> start_local_couchdb.py seems pretty straightforward
[15:20] <thisfred> pitti: well not if it were the only couchdb :)
[15:20] <thisfred> mdz, not super hard, it just means an extra SRU
[15:20] <mdz> it looks like it will already DTRT if the COUCHDB environment variable is set to an alternative binary
[15:20] <thisfred> which I don't think we'll get around anyway
[15:21] <Chipaca> and modifying desktopcouch in that sru in a way that won't be as tested as what we're replacing
[15:21] <mdz> thisfred: an extra compared to what?
[15:21] <mdz> surely desktopcouch needs to be updated anyway
[15:21] <Chipaca> the difference is between updating just the packaging, and updating the code also
[15:21] <thisfred> mdz, it would not if we updated the system couchdb
[15:21] <thisfred> which I know we won't
[15:22] <mdz> thisfred: so if a 10.04 system gets couchdb updated to 1.0, the broken bits of U1 start working with no other changes?
[15:23] <thisfred> yep
[15:23] <Chipaca> pitti: the difference is that if we make the packages conflict, we get away with not touching desktopcouch code, which is a good thing for a stable release, right?
[15:24] <pitti> well, it's not the lines of code that we change
[15:24] <pitti> by that measure, introducing a new package would be way off scale
[15:24] <pitti> it's about the greatest possible damage we can do to existing working setups
[15:25] <pitti> Chipaca: if we make the packages conflict, then we couldn't pull in couchdb-1.0 automatically during upgrade
[15:25] <pitti> since couchdb is already installed
[15:25] <pitti> and the entire exercise would be moot, wouldn't it?
[15:25] <mdz> pitti++
[15:25] <mdz> it's about risk
[15:25] <rickspencer3> may I offer my opinion?
[15:25] <mdz> of course
[15:25] <rickspencer3> (even if people won't like it?)
[15:25] <pitti> and we can't just force-remove couchdb
[15:25] <pitti> rickspencer3: please
[15:25] <rickspencer3> My view is that CouchDB missed the Lucid the train
[15:26] <rickspencer3> I understand this is painful as we would like to provide services to Lucid users
[15:26] <rickspencer3> However, I feel this effort is now misdirected
[15:27] <mdz> I think there is a way this could be done which would sufficiently contain the risk to 10.04 users, such that we would be comfortable releasing it
[15:27] <thisfred> I respectfully disagree, I think the side-by-side solution is still worth the (little extra) effort, if the TB approves it
[15:27] <mdz> but it will be up to the U1 team whether that effort would be well spent
[15:27] <rickspencer3> it's not just effort on their part
[15:27] <pitti> right, with pretty much parallel packages
[15:28] <thisfred> pitti: yep
[15:28] <rickspencer3> this will cause effort to be expended across the organization
[15:28] <mdz> it may be that effort would be better invested in making the changes in natty such that we can issue future updates without a problem
[15:28] <rickspencer3> and Chipaca already said they lack the resources themselves to do proper packaging
[15:28] <pitti> thisfred: I have no objections against a side-by-side approach; it still requires a formal exceptoin, as it's outside of the usual SRU boundaries, but it has a manageable risk, so I'd agree to it
[15:28] <mdz> I'm with pitti
[15:29] <rickspencer3> well, I don't think it's worth the risk or the effort
[15:29] <pitti> but yes, mdz raises a good point -- we should make sure that if this happens again we are better prepared
[15:29] <rickspencer3> and the effort is not just on the U1 team
[15:29] <pitti> perhaps we should have a separate desktopdouch-server package which just talks to desktopcouch, and not use the "official" couchdb package at all
[15:29] <mdz> rickspencer3: fair point, there is other effort involved which perhaps we haven't included in our implicit estimate
[15:30] <mdz> I'm not prepared to offer the U1 team advice on whether this is worth it or not, at least not with my TB hat on
[15:30] <mdz> but they are welcome to ask me for my Canonical opinion separately
[15:30] <rickspencer3> mdz, well, with my Director of Engineering hat on, I feel I should offer my views
[15:30] <thisfred> just as a thought experiment, if we were to put couchdb 1.0 in backports
[15:30] <thisfred> would that be acceptable?
[15:30] <pitti> yes IMHO
[15:31] <rickspencer3> isn't that specifically what backports if for?
[15:31] <pitti> we make no promises wrt. API stability in backports
[15:31] <Chipaca> backports are not enabled by default, right?
[15:31] <pitti> correct
[15:31] <Chipaca> ok
[15:31] <mdz> I do feel that, based on the analysis I've seen, and the survey results, updating the couchdb package itself is not in the best interest of our user base as a whole
[15:31] <pitti> which is why we can be liberal there
[15:31] <thisfred> Of course most people using lucid for stability reasons won't have backports on...
[15:31] <mdz> rickspencer3: you absolutely should. I'm just explaining why I'm neither agreeing nor disagreeing with you :-)
[15:31] <pitti> thisfred: so people who care about U1 syncing, and don't need existing couchdb could just grab it from backports, you mean?
[15:31] <rickspencer3> right
[15:32] <thisfred> pitti: yeah
[15:32] <mdz> couchdb 1.0 in backports is OK with me as well, and I expect the backports team would be amenable
[15:32] <thisfred> pitti: though the downside is that they'd have to be made aware of this
[15:32] <pitti> it would mean backports of couchdb and desktopcouch; anything else?
[15:32] <mdz> thisfred: it would also entail testing both upgrade paths, if you want to support those users properly
[15:32] <thisfred> pitti: nope, and not even desktopcouch if we don't do the parallel install there
[15:33] <aquarius> thisfred, couch 1.0 doesn't need a newer spidermonkey?
[15:33] <pitti> thisfred: lucid's desktopcouch doesn't need updates to talk to an 1.0 couchdb API? that did change
[15:34] <thisfred> pitti: no, the API (that desktopcouch cares about) did not change between 0.10 and 1.0
[15:34] <pitti> thisfred: but anyway, I could even envision an SRU which checks for this situation if you try to enable non-file sync, and guides you to a website which explains the situation and how to install backports
[15:34] <thisfred> pitti: we'd only need to make changes to d-c if we were to have the parallel install
[15:35] <pitti> thisfred: ok, then couchdb backport plus changes to point to documentation ("install couchdb from backports; don't if you have existing couchdb...") seems feasible?
[15:35] <mdz> option 1: parallel package couchdb 1.0, update desktopcouch to use it, and release via SRU exception
[15:35] <mdz> option 2: parallel package couchdb 1.0, update desktopcouch to use it, and release via backports
[15:35] <thisfred> aquarius: I thought not, but that still doesn't impact desktopcouch. It would mean another SRU if it's true and we don't go the backports route
[15:36] <Chipaca> oh, I was reading option 2 as non-parallel
[15:36] <mdz> option 3: update couchdb to 1.0 in backports, superseding 0.1 in lucid
[15:36] <pitti> mdz: I think option 2 is "backport maverick couchdb", no parallel install, right?
[15:36] <Chipaca> ah
[15:36] <pitti> ah, right
[15:36] <Chipaca> it's 0.10, not 0.1 :)
[15:36] <mdz> Chipaca: sorry
[15:36] <mdz> s/0.1/0.10/
[15:36] <pitti> I think we can rule out 2
[15:36] <pitti> it's almost as much effort as 1 but a lot less benefit
[15:36] <thisfred> right
[15:36] <mdz> ok
[15:36] <rickspencer3> mdz is there not an option to simply move on?
[15:37] <Chipaca> and about the sru of the control panel to alert users of the availability of the fix, is tehre agreement on that?
[15:37] <mdz> option 4: do nothing, focus on natty, move on
[15:37] <mdz> rickspencer3: yes!
[15:37] <rickspencer3> :)
[15:37] <mdz> any other options?
[15:37] <Chipaca> mdz: does option 2 include the ubuntuone-preferences sru to alert users of the issue?
[15:38] <Chipaca> um, option 3 i meant
[15:38] <pitti> mdz's option list seems complete to me
[15:38] <aquarius> "option 5: backport 1.0 to lucid, breaking people who are reliant on specific aspects of 0.10 in lucid" is entirely off the table, yes?
[15:38] <mdz> Chipaca: I'm not familiar with that idea
[15:38] <aquarius> (er, s/backport/SRU/, sorry)
 thisfred: but anyway, I could even envision an SRU which checks for this situation if you try to enable non-file sync, and guides you to a website which explains the situation and how to install backports
[15:38] <Chipaca> mdz: ^
[15:38] <rickspencer3> wow
[15:39] <pitti> aquarius: I'd vote against it, so you'd need to convince another majority of the TB
[15:39] <aquarius> pitti, just making sure the option list is complete. :)
[15:39] <mdz> aquarius: I'm with pitti
[15:39] <pitti> aquarius: but yes, it'd complete the option list
[15:40] <mdz> Chipaca: thinking
[15:40] <rickspencer3> well, I guess there are options that the TB would accept, and then options that Ubuntu Engineering would be willing to support with resources
[15:40] <rickspencer3> that list may not be the same
[15:41] <mdz> so this would be a minimal SRU which changed the software to notify the user of the situation and how to proceed?
[15:41] <pitti> (raises some questions wrt. adding translatable strings, and translating the web page, but I think we could fit that in)
[15:41] <mdz> I think that could be done in a way that would be acceptable to the SRU team
[15:42] <pitti> or skip the web page and try to come up with a short text
[15:42] <mdz> any objections to dropping option 2 because it's dominated by the others?
[15:43] <thisfred> mdz +1 on dropping 2.
[15:43] <mdz> done
[15:43] <mdz> option 1: parallel package couchdb 1.0, update desktopcouch to use it, and release via SRU exception
[15:43] <mdz> option 3: update couchdb to 1.0 in backports, superseding 0.1 in lucid
[15:43] <mdz> option 4: do nothing, focus on natty, move on
[15:43] <pitti> mdz: +1 on dropping 2
[15:43] <pitti> thisfred, aquarius: hm, we could even check if there are local systemwide couchdbs
[15:44] <pitti> and only show that note if there aren't
[15:44] <mdz> benefits of 1: might make future updates easier
[15:44] <mdz> costs of 1: relatively large development and testing effort
[15:44] <mdz> benefits of 3: relatively small development and testing effort
[15:44] <aquarius> pitti, which is basically defined by "do you have the couchdb package installed", because that's what provides the system couchdb (d-c depends on couchdb-bin, which provides the binaries etc but not the init scripts and so on)
[15:44] <pitti> 1 sounds like a good future path from natty on (i. e. have a desktopcouch-private couchdb server package)
[15:44] <mdz> benefits of 3: zero impact to users who do not use U1
[15:45] <pitti> aquarius: could be; that, or checking the data dir
[15:45] <mdz> disadvantages of 3: more fiddly for users who do use U1
[15:45] <pitti> mdz: "... want to use more features of U1"
[15:45] <mdz> pitti: ack
[15:46] <mdz> benefits of 4: zero development and testing effort, strong focus on current development and forward momentum
[15:46] <mdz> disadvantage of 4: disappoint people who want the new features on LTS
[15:46] <mdz> what else have I missed?
[15:46] <aquarius> mdz: "...who want the *existing* features on LTS"
[15:47] <Chipaca> another disadvantage of 4: for a non-ignorable number of people, ubuntu one will (continue to be) "just file sync"
[15:47] <mdz> aquarius: did they actually lose features they had when 10.04 came out?
[15:47] <pitti> mdz: thanks for summarizing; looks complete to me
[15:47] <Chipaca> mdz: yes, the features worked on release
[15:47] <Chipaca> mdz: and then buckled under load
[15:48] <mdz> ok, so we had to regress them in order to get it working for anybody
[15:48] <rickspencer3> well, it worked on the client, but from the users point of view, it did not work
[15:48] <mdz> and they probably didn't use it for very long
[15:48] <mdz> in effect, it shipped without the functionality, no?
[15:48] <mdz> it = 10.04
[15:48] <rickspencer3> in effect
[15:49] <mdz> is there anything more for the TB to decide?
[15:49] <rickspencer3> you could/can store data in couchdb, but there is no syncing and it fails silently
[15:49] <thisfred> in effect yes, as we had to disable replication on the server very soon after release
[15:49] <Chipaca> i disagree with rickspencer3, but I know we disagree
[15:50] <mdz> we've outlined multiple options and evaluated the pros and cons, I think the final call is up to the U1 team as to which is the best use of their energy
[15:50] <pitti> with my TB hat on, I'd approve any of 1, 3, 4
[15:50] <pitti> with my developer hat on, I think we should at least do 3
[15:50] <mdz> we have another item on the agenda which wendar has been waiting patiently to discuss
[15:50] <pitti> then clean up the situation in natty (with an approach like 1)
[15:50] <pitti> and then perhaps reconsider later on if this can be backported
[15:51] <Chipaca> mdz: to make things clear, we decide which way forward is best, and the TB approves of it?
[15:51] <Chipaca> of these options
[15:52] <pitti> sounds fine
[15:52] <pitti> Chipaca: but it seems you can do any of above option, and it'd get the TB's approval
[15:52] <mdz> Chipaca: yes, pretty much. I think we need some oversight on the details if it's 1 or 3
[15:52] <mdz> so we should stay in touch
[15:52] <mdz> but you would have our blessing
[15:53] <Chipaca> ok, thank you
[15:53] <mdz> [topic] ARB exception proposal - Allison Randal
[15:53] <MootBot> New Topic:  ARB exception proposal - Allison Randal
[15:53] <mdz> wendar, thanks for your patience
[15:53] <wendar> IIRC, there's another meeting here on the hour. A quick summary:
[15:53] <wendar> - Allow .desktop files to be installed outside /opt.
[15:54] <wendar> - In Natty, we'll modify Quickly, cdbs, python-support, and related packages o support installation in /opt.
[15:54] <wendar> - For Maverick, accept that .pyc files and version symlinks won't be generated for Python libraries.
[15:54] <wendar> - For Maverick, ARB will perform manual package fixes on proposed applications, to install in /opt and load libraries from /opt.
[15:54] <wendar> - Binaries only in /opt (no exceptions for Maverick), will not be in $PATH.
[15:54] <wendar> - Official install location is /opt/extras.ubuntu.com/<packagename> (with version number? i.e. "/opt/extras.ubuntu.com/foo-1.5")
[15:55] <pitti> (for the record, natty's cdbs/quickly/etc. already support this)
[15:55] <wendar> The last we would especially like decided today, as the modifications for Natty packages are ready to go but waiting on that path to be finalized before merging.
[15:55] <persia> Why except .desktop files: couldn't they be pulled by extending DefaultAppDirs in some package in extras upon which things depend?
[15:56] <wendar> persia: no part of the system knows how to pull .desktop files from non-standard paths
[15:56] <mdz> wendar: I'm a bit concerned on behalf of the ARB about the expectation that they will fix up the packages as needed
[15:56] <wendar> persia: we can modify it for Natty, but not for Maverick
[15:56] <mdz> but I guess you can speak for yourselves on that point?
[15:57] <wendar> mdz: yes, that manual work is not something we could do for the long-term, but for Maverick we have few submissions
[15:57] <wendar> mdz: only 4 at the moment
[15:57] <persia> wendar, The menu-xdg package has an implementation that pulls from /var/lib/menu-xdg/applications/menu-xdg
[15:57] <pitti> persia: can you extend the .desktop search path with an extra conffile?
[15:57] <persia> pitti, Yep.
[15:57] <pitti> (I know, *I* ought to know this, but I don't, sorry)
[15:58] <persia> Well, I should say you *could*.  I haven't dug deeply in menus for > 18 months.
[15:58] <mdz> wendar: binaries only in /opt = "binaries nowhere else but in /opt", not "nothing in /opt which is not a binary", right?
[15:58] <wendar> persia: can we modify it to pull .desktop files from /opt/extras.ubuntu.com/applications without modifying any system packages?
[15:58] <pitti> /etc/xdg/menus/applications.menu just says <DefaultAppDirs/>
[15:58] <pitti> but my concern is that this would need modification of gnome-menus, the KDE counterpart, and any other desktop env
[15:58] <persia> wendar, I believe so, but it would take me a few hours to chase the how.
[15:59] <pitti> mdz: confirmed; it's "no files outside /opt", except perhaps .desktop
[15:59] <wendar> pitti: yes
[16:00] <mdz> the .pyc and symlink stuff is definitely OK by me
[16:00] <mdz> if the ARB is ok with fixing up the packages, I'm OK with t hat too
[16:00] <mdz> no-binaries-outside-of-/opt seems sensible enough
[16:00] <mdz> the extras.ubuntu.com path also sounds fine
[16:00] <mdz> so the only question is about how to handle .desktop files?
[16:01] <wendar> yes, just .desktop
[16:01] <mdz> I don't know how many programs use /usr/share/applications
[16:01] <wendar> and, whether to use the path /opt/extras.ubuntu.com/
[16:01] <mdz> but AIUI the standardized interface is the filesystem
[16:01] <persia> mdz, ~90%, and everything with a menu entry uses that or a subdirectory.
[16:01] <wendar> mdz: the intention is that most of these apps will be using .desktop files
[16:01] <mdz> is it not workable to install the .desktop files in /opt and symlink them to /usr?
[16:02] <wendar> mdz: yes, a symlink would be workable
[16:02] <mdz> persia: I meant, how many programs *read* the list of .desktop files
[16:02] <wendar> mdz: it would still pollute the general namespace, but preserves the principle of "install in /opt"
[16:02] <mdz> wendar: a symlink would at least give correct behavior if the stuff in /opt went away
[16:02] <persia> Oh.  Six, last I counted (7.10)
[16:02] <mdz> but if that's managed by the package manager, I don't suppose that's a problem
[16:03] <pitti> I don't see much difference between symlink and actually installing into /u/s/a/, but symlink sounds fine
[16:03] <mdz> I'm happy either way
[16:03] <mdz> pitti: I was thinking of opt as something which is managed outside of the package manager, but in this case of course it isn 't
[16:03] <wendar> okay, so approved a symlink for .desktop files outside /opt?
[16:03] <mdz> I was worried about dangling .deskto pfiles
[16:03] <pitti> wendar: would be interesting to investigate enlarging the search path in natty
[16:03] <wendar> and I'll work with persia to see if we can get actual load from /opt working
[16:03] <pitti> to pick up desktop files in /opt
[16:03] <mdz> wendar: I think it's unnecessary complexity, installing directly in /usr should be OK
[16:04] <mdz> (installing .desktop files in /usr, I mean, of course)
[16:04] <pitti> ^ especially since these get manual review for sanity
[16:04] <persia> wendar, Sounds good.  I know we have some implementations that *change* the menu files in various ways with additional packages: just needs some digging to get the right XML.
[16:04] <wendar> then, approved to install .desktop files in /opt, if we can't find a workaround for Maverick
[16:04] <wendar> for Natty, we should have .desktop files in /opt working
[16:04] <mdz> we don't actually have a quorum of the TB here, I don't think
[16:04] <pitti> wendar: you mean "approved .. in /usr/s/apps/"
[16:04] <mdz> so if you need an official vote or something, we'll have to take it to email
[16:05] <wendar> pitti: aye
[16:05] <mdz> but it sounds sane to me
[16:05] <pitti> but that has already been brought up on the list without opposition
[16:05] <mdz> we need to clear out to let the server team have their meeting
[16:05] <pitti> great
[16:05] <wendar> then, last thing: /opt/extras.ubuntu.com/?
[16:05] <pitti> +1 (as I said on the ML)
[16:05] <mdz> wendar: I said +1 above as well
[16:06] <mdz> done?
[16:06] <wendar> done, thanks!
[16:06] <mdz> I don't see anything else on the mailing list
[16:06] <mdz> so that's a wrap, thanks all
[16:06] <mdz> #endmeeting
[16:06] <MootBot> Meeting finished at 10:06.
[16:06] <pitti> thanks all
[16:06] <hggdh> ~ô~
[16:06] <Daviey> \o/
[16:06] <JamesPage> o/
[16:06] <hallyn_> \o
[16:07] <JamesPage> looks like most folk are here so lets make a start
[16:07] <robbiew> *\o/*
[16:07] <JamesPage> #startmeeting
[16:07] <MootBot> Meeting started at 10:07. The chair is JamesPage.
[16:07] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:07] <kirkland> o/
[16:07] <jj-afk> \o
[16:07] <JamesPage> [TOPIC] Review ACTION points from previous meeting
[16:07] <MootBot> New Topic:  Review ACTION points from previous meeting
[16:07] <JamesPage> ALL: please check the SRU tracker https://wiki.ubuntu.com/ServerTeam/SRUTracker and help out with verification
[16:07] <ttx> o/
[16:08] <JamesPage> so hows that going for everyone?
[16:08] <hggdh> \life is good, and Hudson kicks
[16:08] <zul> hi
[16:08] <Daviey> JamesPage: pretty good!
[16:09] <hallyn_> JamesPage: well, so i'm still not 100% clear on what we do with those
[16:10] <hallyn_> do we set up an environment to test the fix in, so we can comment 'fix works'?
[16:10] <zul> umm...that page is really really old
[16:10] <JamesPage> zul: do you have a more up-to-date view...
[16:10] <hallyn_> robbiew had given us one
[16:11] <hallyn_> i wonder if i pasted the wrong link two weeks ago into the action
[16:11] <zul> JamesPage: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html
[16:11] <hallyn_> i thought that one was old too
[16:11] <zul> hallyn_: nope thats the latest and greatest as of this morning
[16:11] <JamesPage> Is the concern the size of the 'unassigned bugs' list?
[16:12] <SpamapS> o/
[16:12] <SpamapS> this time stinks for me btw.
[16:12] <SpamapS> JamesPage: the concern is actually the verification needed bugs
[16:13] <JamesPage> SpamapS: right - I think that answers the question
[16:13] <hallyn_> does it?
[16:14] <JamesPage> So its about testing SRU's which are in -proposed and need to be verified (only four at the moment)
[16:14] <robbiew> the verification needed bugs list is short, right?
[16:14] <SpamapS> JamesPage: 4 is a lot IMO.. those are bugs that are fixed and just need to be checked out.
[16:14] <hallyn_> ok.  presumably we really ought to lean on the bug submitter to test?
[16:14] <Daviey> I think this requires a whole agenda item.... "SRU:  What it means to us ":)
[16:15] <hallyn_> but, failing that, we set up a hardy image or whatever and d oit?
[16:15] <hggdh> d oit?
[16:15] <SpamapS> hallyn_: no the idea is to have somebody who is not the submitter test
[16:15] <Daviey> hallyn_: The release / QA team are currently discussing a best pratice for verification
[16:15] <zul> SpamapS: compared to the unassigned bugs and assigned bugs 4 is not alot
[16:16] <SpamapS> hggdh: its french for "get 'er done"
[16:16] <Daviey> it is bad form for the bug raiser and fixer to verify their own work.
[16:16] <hallyn_> hggdh: my space key seems to have a longer travel depth than other keys
[16:16] <hggdh> heh
[16:17] <JamesPage> OK before we get to bogged down in this
[16:17] <hallyn_> Daviey: ok
[16:17] <JamesPage> The immediate focus is to verify the 'needs-verification' bugs
[16:17] <JamesPage> SpamapS: we carried this over from last weeks meeting as you where due to submit a proposal
[16:18] <JamesPage> I suggest we carry again until this is agreed and try to put some immediate focus on the current list.
[16:18] <Daviey> +1
[16:18] <SpamapS> Agreed, I'll send the proposal ASAP as well.
[16:18] <JamesPage> [ACTION] ALL: please check the SRU tracker http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html for 'needs-verification' bugs
[16:18] <MootBot> ACTION received:  ALL: please check the SRU tracker http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html for 'needs-verification' bugs
[16:19] <JamesPage> robbiew to review /ServerTeam wiki
[16:19] <hggdh> +1 -- it might be a good thing to go on over the unassigned list and (perhaps) clean it up
[16:20] <SpamapS> hggdh: I think its probably time to start marking dapper bugs Won't Fix
[16:20] <hggdh> SpamapS: it might. But we need a clear ack from management
[16:20] <robbiew> yeah....that's a todo for this week...the f*$#ing wiki!!! lol
[16:20] <SpamapS> I thought in the final year it was "security only" ?
[16:20] <JamesPage> ok carried forward
[16:20] <zul> SpamapS: desktop i think
[16:21] <JamesPage> [ACTION] robbiew to review ServerTeam wiki
[16:21] <MootBot> ACTION received:  robbiew to review ServerTeam wiki
[16:21]  * SpamapS has no idea where or even if thats written down
[16:21] <Daviey> defacto :)
[16:21] <JamesPage> SpamapS to email a concrete proposal for addressing SRU verification backlog
[16:21] <SpamapS> JamesPage: right, same thing, carry to next week
[16:21]  * SpamapS will send it RSN
[16:22] <JamesPage> [ACTION] SpamapS to email a concrete proposal for addressing SRU verification backlog
[16:22] <MootBot> ACTION received:  SpamapS to email a concrete proposal for addressing SRU verification backlog
[16:22] <JamesPage> Next: Kernel team to follow up on EC2 status
[16:23] <Daviey> smb / jjohansen ?
[16:23] <jjohansen> have done some testing with Bug #669496
[16:24] <jjohansen> and we may have a solution, but it needs more testing first
[16:24] <Daviey> \o/
[16:25] <jjohansen> iscsi target has a newer version being built in dkms so we are planning to drop it for the kernel proper
[16:25] <Daviey> jjohansen: Is the kernel team testing that, or is it smoser ?
[16:25] <jjohansen> Daviey: I have been playing with it, and once we verify we will hand over to smoser to test
[16:25] <Daviey> rocking
[16:26] <jjohansen> I just don't trust my results from yesterday :)
[16:26] <Daviey> jjohansen: Is it likely to be resolved before thursday (if your fix works) ?
[16:26] <jjohansen> hrmmm, maybe
[16:26] <smoser> oh hey.
[16:27] <jjohansen> that is we can submit the fix (assuming I get the same results)
[16:27] <jjohansen> but it maybe to late for the kernel already
[16:27] <Daviey> just wondering if we are likely to see the fix in Alpha 1 release.
[16:27] <smoser> jjohansen, i'll bother you outside of meeting, i had accepted there would be no i386 amis for alpha1
[16:27] <jjohansen> generally kernel fixes need to be in a week before other stuff
[16:28] <smoser> but i surely would be grateful if it happened to work
[16:28] <jjohansen> well I booted a couple i386 amis last night
[16:28] <Daviey> \o/
[16:29] <JamesPage> OK so anything else for the Kernel team on ec2 status for natty?
[16:29] <smoser> if it is low risk to other things, i would say go for it.
[16:29] <jjohansen> smoser: well its sort of low risk, it involves turning off pv-on-hvm
[16:30] <smoser> yuck
[16:30] <jjohansen> yeah
[16:30] <JamesPage> Next ACTION to review: Kernel team to follow up on bug 661294
[16:31] <jjohansen> smb: was looking into this, and I don't believe their is any resolution yet
[16:31] <jjohansen> at least I don't see anything in my notes from him
[16:31] <smb> waiting on feedback
[16:32] <jjohansen> oh, \o/
[16:32] <jjohansen> morning smb :)
[16:32] <smb> still on phone typing one handed
[16:32] <jjohansen> I was just about to say, found it "no usable feedback"
[16:32] <SpamapS> smb: eyes on the road!
[16:32] <ttx> tmi
[16:33] <Daviey> !
[16:33] <JamesPage> Do we want to carry this one to next week?
[16:33] <SpamapS> sounds like it
[16:34] <JamesPage> [ACTION] Kernel team to follow up on bug 661294
[16:34] <MootBot> ACTION received:  Kernel team to follow up on bug 661294
[16:34] <JamesPage> Moving on....
[16:34] <JamesPage> [TOPIC] Natty Development
[16:34] <MootBot> New Topic:  Natty Development
[16:35]  * SpamapS hears crickets
[16:35] <hallyn_> i sure do wish firefox plugins work, but other than that natty is treating me well :)
[16:35] <SpamapS> I think its about time we set the trend line here: http://people.canonical.com/~platform/workitems/natty/canonical-server.html
[16:36] <SpamapS> Unless anybody has some giant new stuff they expect to land in their BP's soon?
[16:36] <jjohansen> hallyn_: what video card because X keeps dying on me
[16:36] <SpamapS> I'll go ahead and do that as I have commit access to the wi tracker.
[16:36] <hallyn_> i do need to make my bp work items lists more precise
[16:36] <hallyn_> jjohansen: oh, nvidia is a fail for me right now.  non-accelerated nouveau
[16:37] <ttx> SpamapS: who needs a trends line set when there is... inverted burndown charts !
[16:37] <jjohansen> ah, I'm using an intel igp - can't even make it to the desktop :(
[16:37] <SpamapS> hallyn_: I think its actually better to keep them coarse and just try to get a gross estimate of the work so you can plan accordingly. Precision at this stage can sometimes lock us into a course of action that doesn't make sense.
[16:38] <JamesPage> Daviey, zul, kirkland, smoser - are you guys happy with the state of your wi's before we do this?
[16:38] <SpamapS> ttx: I don't think anybody else liked those except you and me. ;)
[16:38] <hallyn_> SpamapS: hm, i guess i'm just not comfortable with work items in a bunch of blueprints instead of just one :)
[16:38] <ttx> SpamapS: We are the only true admirers of real art. Like the bp lp api.
[16:38] <SpamapS> JamesPage: its entirely changable too, so no big deal if people add more later.
[16:38] <kirkland> JamesPage: meh, happy enough
[16:39] <SpamapS> but it seems like we have a decent number.. 360
[16:39] <smoser> well, my blueprints correctly show my poor progress
[16:39] <zul> doesnt matter either way to me
[16:39] <Daviey> JamesPage: I can't see a problem with starting now
[16:39] <SpamapS> ttx: indeed
[16:39] <JamesPage> [ACTION] SpamapS to setup trend line for server team natty work items
[16:39] <MootBot> ACTION received:  SpamapS to setup trend line for server team natty work items
[16:39] <JamesPage> done
[16:39] <SpamapS> BP's are getting an API btw.
[16:39] <SpamapS> if any of you missed that
[16:39] <hallyn_> i did.  yay
[16:40] <robbiew> fwiw, I'd rather have coarse WIs than none at all
[16:40] <ttx> SpamapS: Christmas is early, maybe Dec 8.
[16:40] <Daviey> ttx: My calendar says otherwise!
[16:40] <ttx> Daviey: I use a metric calendar.
[16:40] <robbiew> ttx: could you guys get us sortable/customizable bug columns while you're at it
[16:40] <robbiew> :)
[16:40] <JamesPage> OK so if we are done with Natty development lets move onto....
[16:41] <JamesPage> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[16:41] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[16:41] <hggdh> k
[16:41] <ttx> robbiew: that migth be asking too much. It's already a miracle to get the Api while BP are still planned to be merged with bugs, long-term :)
[16:41] <hggdh> I have a blocker -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/676245
[16:41] <Daviey> :(
[16:41] <Daviey> smb / jjohansen ^^ ?
[16:41] <Daviey> (That is blocking our test rig)
[16:42] <hggdh> Tim is working on it, but we need it for alpha1 testing
[16:42] <hallyn_> bug 676245
[16:42] <jjohansen> hggdh: oh, not nice
[16:42] <jjohansen> I know its being looked at
[16:42] <smb> And the first time we probably hear of it?
[16:42] <jjohansen> actually tim was talking about it this morning
[16:42] <smb> I think JFo was mentioning that a bit ago on kernel
[16:42] <jjohansen> yeah
[16:43] <smb> Cannot say much there. Just finished a phone call
[16:43] <JFo> yep :)
[16:44] <jjohansen> I don't think there is much to say beyond tim assigned
[16:45] <hggdh> yes, I am just raising up the issue -- we have not been able to test either Euca or openstack
[16:45] <hggdh> on Natty
[16:45] <jjohansen> :(
[16:45] <hggdh> apart from that -- thanks to JamesPage, Hudson is up & running on AWS
[16:46] <hggdh> so if you want to add slave machines to it... Welcome! and ping James or me to add you as an user
[16:46] <JamesPage> hggdh - we also have a first set of ISO install test results - not to bad
[16:46] <hggdh> indeed -- only 4 failures, and I will be looking at them in a few
[16:47] <JamesPage> ping me afterwards - I took a look at some of them today.
[16:47] <JamesPage> hggdh: anything else from the QA team?
[16:47] <zul> where is the url for the hudson server anyways?
[16:47] <hggdh> I also added the ISO server results to the QA dashboard (WIP):
[16:47] <JamesPage> You can access it here : http://204.236.234.12:8080/
[16:48] <hggdh> http://reports.qa.ubuntu.com/reports/qadashboard/qadashboard.html
[16:48] <MootBot> LINK received:  http://reports.qa.ubuntu.com/reports/qadashboard/qadashboard.html
[16:48] <hggdh> the page is not yet updated, BTW
[16:48]  * Daviey actions JamesPage to arrange a URL for it. :)
[16:48] <Daviey> subdomain
[16:48] <JamesPage> Daviey: agreed
[16:48] <hggdh> for the record, this Hudson server is *temporarily* on AWS, we intend to move it later on
[16:48] <JamesPage> [ACTION] JamesPage to arrange URL for Hudson CI Server
[16:48] <MootBot> ACTION received:  JamesPage to arrange URL for Hudson CI Server
[16:49] <hggdh> and that's it, right now, from QA
[16:49] <JamesPage> Excellent
[16:49] <JamesPage> [TOPIC] Weekly Updates & Questions for the Kernel Team (smb)
[16:49] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (smb)
[16:50] <Daviey> I think they've already done a dandy job of telling us quite a bit
[16:50] <jjohansen> hrmm, I don't have any updates beyond what has already been covered
[16:50] <smb> jjohansen, Did we ask about iscsitarget?
[16:51] <jjohansen> Ah, well I mentioned it in the wrong place but yeah
[16:51] <jjohansen> hrmm, though I made it more a statement than a request
[16:52] <JamesPage> Anything else from the QA team
[16:53] <JamesPage> /QA/Kernel/
[16:53] <smb> jjohansen, If the statement was "I don't think you still need that" and nobody ran screaming it is ok. :)
[16:53] <JamesPage> [TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)
[16:53] <MootBot> New Topic:  Weekly Updates & Questions for the Documentation Team (sommer)
[16:53] <Daviey> no sommer :(
[16:53] <JamesPage> sommer around today?
[16:53] <jjohansen> smb: well more we are removing it because there is a newer dkms, and no one ran screaming :)
[16:54] <JamesPage> anyone spoken to sommer since UDS?
[16:54] <Daviey> jjohansen: We'll scream if it breaks :P
[16:54] <jjohansen> Daviey: I know you will
[16:54] <smb> Sounded like everybody was using the dkms version anyway
[16:54] <smb> So there would be no change
[16:54] <Daviey> groovy
[16:55] <zul> iscsitarget is already using dkms isnt it?
[16:55] <SpamapS> JamesPage: no, but I believe he was starting a new job so he may not have had as much time to be on IRC or work on Ubuntu
[16:55] <smb> zul, Yes as far as we know
[16:55] <smb> I think its just the same as once with drbd
[16:56] <JamesPage> [TOPIC] Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[16:56] <MootBot> New Topic:  Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[16:56] <kim0> hey everyone o/
[16:56] <JamesPage> o/
[16:56] <kim0> I just started showcasing Ubuntu Cloud stuff through a screencast series. If anyone has suggestions on cool things to demo that set apart Ubuntu server and Cloud, please throw me an email. I need to create a list of things to showcase, so flood me :)
[16:56] <kim0> Other than that, I'm interested in identifying "things the community can help with" as it related to cloud for now
[16:56] <kim0> I'm thinking perhaps UEC QA scenarios might be a good one ? I know the Fedora community helps with lots of the testing, is it a good idea to start doing the same. Who would be interested to push this forward. Can we setup a public UEC testing environment?
[16:57] <kim0> So if anyone working on a cloud related BP can identify "low hanging fruit" (as in fixes/features/QA) to engage more community involvment, please shoot me an email. I need to create a list, and start beating the drum. Your help is needed, so again flood me :)
[16:57] <Daviey> kim0: last question, probably no at the moment
[16:57] <kim0> any thoughts on low hanging fruit .. are most welcome
[16:57] <Daviey> kim0: How are the cloud community meetings going?
[16:57] <kim0> Daviey: the QA ones ?
[16:58] <Daviey> kim0: the meeting you were driving :)
[16:58] <kim0> The first one was good
[16:58] <kim0> not too busy though
[16:58] <kim0> but we did make use of the full hour
[16:58] <Daviey> great!
[16:58] <kim0> it's weekly
[16:58] <kim0> so another one is tomorrow
[16:58] <kim0> I'll try to put some training
[16:58] <Daviey> kim0: Plug it here :)
[16:58] <kim0> stuff in there
[16:58] <kim0> Is it better to use #ubuntu-cloud or here
[16:59] <kim0> anyway .. that should be all for me
[16:59] <SpamapS> those meetings are at 7am pacific time btw
[16:59] <SpamapS> I'm not saying it because I can't make it..
[16:59] <SpamapS> but because the mecca of all web 2.0 / cloud technology.. san francisco .. can't make it
[16:59]  * kim0 nods 
[16:59] <kim0> prolly needs a time change
[17:00] <JamesPage> Any other questions for kim0
[17:00] <JamesPage> ?
[17:00] <Daviey> none here
[17:00] <JamesPage> [TOPIC] Open Discussion
[17:00] <MootBot> New Topic:  Open Discussion
[17:01] <JamesPage> Any items for general discussion?
[17:01] <Daviey> none here
[17:01] <SpamapS> nay say they
[17:01] <Daviey> Can we go home now? :)
[17:01] <JamesPage> Almost[TOPIC] Announce next meeting date and time
[17:01] <kim0> haha :)
[17:01] <JamesPage> [TOPIC] Announce next meeting date and time
[17:01] <MootBot> New Topic:  Announce next meeting date and time
[17:01] <JamesPage> :-)
[17:01]  * bjf is drumming his fingers
[17:01] <JamesPage> Tuesday 2010-12-07 at 1600 UTC - #ubuntu-meeting
[17:02] <JamesPage> #endmeeting
[17:02] <MootBot> Meeting finished at 11:02.
[17:02] <SpamapS> JamesPage: awesome, thanks!!
[17:02] <bjf> #
[17:02] <bjf> # lets "get 'er done"!
[17:02] <bjf> #
[17:02] <JFo> o/
[17:02] <bjf> #startmeeting
[17:02] <MootBot> Meeting started at 11:02. The chair is bjf.
[17:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:02] <smb> \o
[17:02] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:02] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[17:02] <bjf> #
[17:02] <bjf> # NOTE: '..' indicates that you are finished with your input.
[17:02] <bjf> #
[17:02] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:02] <cking> o/
[17:02] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[17:02] <jjohansen> \o
[17:02] <apw> o/
[17:02] <bjf> [TOPIC] ARM Status (bjf)
[17:02] <bjf>  * Marvel (mvl-dove)
[17:02] <bjf>    * Nothing new this week.
[17:02] <bjf>  * Freescale (fsl-imx51)
[17:02] <bjf>    * Discussed merging their latest 2.6.35 BSP to our kernel tree. Might be Maverick.
[17:02] <MootBot> New Topic:  ARM Status (bjf)
[17:02] <bjf>  * Texas Instruments (ti-omap)
[17:02] <bjf>    * Tested Linaro 2.6.35 prebuilt kernel and Linaro 2.6.37 based kernel from their tree on OMAP Beagle board.
[17:02] <bjf>    * Linaro kernel works fine with Maverick and Natty minimal root file system.
[17:02] <bjf> ..
[17:03] <bjf> [TOPIC] Release Metrics (JFo)
[17:03] <MootBot> New Topic:  Release Metrics (JFo)
[17:03] <JFo> Release Meeting Bugs (6 bugs, 14 Blueprints)
[17:03] <JFo> [17:03] <JFo>  * 0 linux kernel bugs (no change)
[17:03] <JFo>  * 0 linux-ti-omap bugs (no change)
[17:03] <JFo>  * 0 linux-meta-ti-omap bug (no change)
[17:03] <JFo> [17:03] <JFo>  * 5 linux kernel bugs (up 2)
[17:03] <JFo>  * 0 linux-ti-omap bugs (no change)
[17:03] <JFo>  * 0 linux-meta-ti-omap bug (no change)
[17:03] <JFo> [17:03] <JFo>  * 6 blueprints (Including HWE Blueprints)
[17:03] <JFo> [17:03] <JFo>  * [[https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on | Bugs with Patches]]
[17:03] <JFo>  * [[http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/ | Breakdown by status]]
[17:03] <JFo> ..
[17:03] <bjf> [TOPIC] Blueprints: Natty Bug Handling (JFo)
[17:03] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-bug-handling
[17:03] <MootBot> New Topic:  Blueprints: Natty Bug Handling (JFo)
[17:03] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-bug-handling
[17:04] <JFo> * Started on the list of bugs from the 5 teams that we identified as being where our most critical bugs come from.
[17:04] <JFo>   The list is available in its current form: http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
[17:04] <JFo>   It is still very rudimentary, but your feedback on it is still welcome.
[17:04] <JFo> * I've also changed the bugs with patches item to in progress due to my initial review of the bugs as they currently
[17:04] <JFo>   stand. I have also begun doing some draft documentation on how to address these bugs in the proper way. I will
[17:04] <JFo>   be working with several of you to further refine this information in the near future.
[17:04] <JFo> * Started looking at the arsenal scripts we have currently with a view toward getting them back running daily. I
[17:04] <JFo>   have several tasks identified for this week concerning documenting their process as well as working with
[17:04] <JFo>   Deryck H to address the limitation on how many can be processed at one shot.
[17:04] <JFo> ..
[17:05] <bjf> [TOPIC] Blueprints: Kernel Configuration Review (apw)
[17:05] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review
[17:05] <MootBot> New Topic:  Blueprints: Kernel Configuration Review (apw)
[17:05] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review
[17:05] <apw> All configuration changes from the UDS review session are now applied and uploaded. Also the AGP drivers of interest have been identified and moved built-in. An ubuntu kernel with XEN_PCI_PLATFORMDEV has been tested in an Amazon Cluster Compute image. Further testing is needed within an Ubuntu Cluster Compute image, and testing is needed to see if it isn't causing some of the issues in Bug #669496. Work benchmarking the effect of changing HZ is ongoin
[17:05] <apw> g with a report due by natty-alpha-1.
[17:05] <apw> ..
[17:06] <bjf> [TOPIC] Blueprints: Enhancements to the firmware test suite (cking)
[17:06] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
[17:06] <MootBot> New Topic:  Blueprints: Enhancements to the firmware test suite (cking)
[17:06] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
[17:06] <cking> Changes to fwts (natty development branch):
[17:06] <cking>  * ACPI method testing: add some more advice feedback, check for infinite
[17:06] <cking>    loop exeception errors.
[17:06] <cking>  * bios mtrr tests: skip MtrrFixDramModEn test for non-AMD CPUs
[17:06] <cking>  * acpitables: some MADT / APIC sanity checks, dump out P_LVL3_LAT correctly
[17:07] <cking> ..
[17:08] <cking> hrm, missed some lines:
[17:08] <cking>  * bios mtrr tests: skip MtrrFixDramModEn test for non-AMD CPUs
[17:08] <cking>  * acpitables: some MADT / APIC sanity checks, dump out P_LVL3_LAT correctly
[17:08] <cking>  * get ACPI version number from /sys/module/acpi/parameters/acpica_version
[17:08] <cking>  * various build warning fixes
[17:08] <cking> ..
[17:08] <bjf> [TOPIC] Blueprints: Handling of Deviations from Standard Kernels (smb)
[17:08] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance
[17:08] <MootBot> New Topic:  Blueprints: Handling of Deviations from Standard Kernels (smb)
[17:08] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance
[17:09] <smb> I added the deviation docs to the kernel trees. So last thing todo is the script.
[17:09] <smb> ..
[17:09] <bjf> [TOPIC] Blueprints: Review of the Stable Maintenance Process (sconklin / bjf)
[17:09] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review
[17:09] <MootBot> New Topic:  Blueprints: Review of the Stable Maintenance Process (sconklin / bjf)
[17:09] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review
[17:09] <sconklin> The first pass through the process went well, although we didn't hold strictly
[17:09] <sconklin> to a two-week cadence, as we started with kernels ready for verification.
[17:09] <sconklin> We had great help from certification on this, and they will have a representative
[17:09] <sconklin> joining us in this meeting starting next week.
[17:09] <sconklin> We learned a lot and are refining the process, documented here:
[17:09] <sconklin> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
[17:09] <sconklin> In preparation for the beginning of the next stable kernel release,
[17:09] <sconklin> we ask that commits to all -next branches be held until the
[17:09] <sconklin> stable kernel team has completed merging those changes with
[17:09] <sconklin> the master branches.
[17:09] <sconklin> We will announce on ubuntu-kernel-team mailing list when the -next
[17:09] <sconklin> branches are open again.
[17:09] <sconklin> ..
[17:10] <apw> sconklin,
[17:10] <apw> could you not move the branch over to a new name
[17:10] <apw> sort of take a snapshot of it to work with
[17:10] <apw> ..
[17:11] <sconklin> apw: yes, That's occurred to me, and I wanted to run it by everyone as a possible new process step. We agreed to the current process of freezing, tho
[17:11] <tgardner> yeah, what apw said. what good is a -next branch if we can't scribble in it?
[17:11] <sconklin> But yeah, it's a trivial way to handle it
[17:11] <sconklin> We still have a short window during which we reset the branch
[17:12] <apw> the process is bound to evolve
[17:12] <sconklin> let's take this offline
[17:12] <sconklin> ..
[17:12] <sconklin> for now the -next branches remain closed, at least for a few hours
[17:12] <sconklin> ..
[17:12] <bjf> [TOPIC] Blueprints: Ubuntu Kernel Delta Review (apw)
[17:12] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-ubuntu-delta-review
[17:12] <MootBot> New Topic:  Blueprints: Ubuntu Kernel Delta Review (apw)
[17:12] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-ubuntu-delta-review
[17:12] <apw> A number of small changes dropping old no longer required patches. 13 of the 19 personal patch reviews are now done. Some of these are likely to miss the natty-alpha-1 deadline, but none are release critical for the milestone.
[17:12] <apw> ..
[17:13] <bjf> [TOPIC] Blueprints: Kernel Version and Flavours (apw)
[17:13] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
[17:13] <MootBot> New Topic:  Blueprints: Kernel Version and Flavours (apw)
[17:13] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
[17:13] <apw> Preliminary testing of the Linaro OMAP3 kernel suggests it does contain the require Ubuntu delta and will boot the Beagle board (our target platform). We are waiting on working ARM CD images to allow substitution of this kernel for further Ubuntu feature testing. As ARM CDs are not expected until the end of the week some of this is likely to miss natty-alpha-1; work items moved out as appropriate.
[17:13] <apw> ..
[17:14] <bjf> [TOPIC] Status: Natty (apw)
[17:14] <MootBot> New Topic:  Status: Natty (apw)
[17:14] <apw> The final kernel for natty-alpha-1 (2.6.37-7.18) has been uploaded, built and is in the archive.  This is a v2.6.37-rc3 based kernel carrying all of the configuration harmonisation and much of the Ubuntu patch delta review feedback.  We are expecting to upload a futher kernel carrying a v2.6.37-rc4 rebase as soon as the milestone freeze lifts.  Please test the alpha CDs once they come out.
[17:14] <apw> ..
[17:14] <bjf> [TOPIC] Security & bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper (sconklin / bjf)
[17:14] <MootBot> New Topic:  Security & bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper (sconklin / bjf)
[17:14] <sconklin> ||                         || Upd./Sec.     || Proposed      || TiP || Verified    ||
[17:14] <sconklin> || Dapper: Kernel          || 2.6.15-55.89  ||               ||     ||             ||
[17:14] <sconklin> || Hardy:  Kernel          || 2.6.24-28.81  ||               ||     ||             ||
[17:14] <sconklin> || =       LRM             || 2.6.24.18-28.7||               ||     ||             ||
[17:14] <sconklin> || Karmic: Kernel          || 2.6.31-22.69  ||               ||     ||             ||
[17:14] <sconklin> || =       mvl-dove        || 2.6.31-214.32 ||               ||     ||             ||
[17:14] <sconklin> || =       ec2             || 2.6.31-307.21 ||               ||     ||             ||
[17:15] <sconklin> || Lucid:  Kernel          || 2.6.32-26.48  ||               ||     ||             ||
[17:15] <sconklin> || =       LBM             || 2.6.32-25.24  || 2.6.32-26.25  ||     ||             ||
[17:15] <sconklin> || =       mvl-dove        || 2.6.32-209.27 ||               ||     ||             ||
[17:15] <sconklin> || =       fsl-imx51       || 2.6.31-608.19 || 2.6.31-608.20 ||     ||             ||
[17:15] <sconklin> || =       ec2             || 2.6.32-309.18 ||               ||     ||             ||
[17:15] <sconklin> || = lts-backport-maverick || 2.6.35.22.34  ||               ||     ||             ||
[17:15] <sconklin> || Maverick: Kernel        || 2.6.35-23.41  ||               ||     ||             ||
[17:15] <sconklin> || =       mvl-dove        || 2.6.32-410.27 || 2.6.32-412.28 ||     ||             ||
[17:15] <sconklin> || =       ti-omap4        || 2.6.35-903.18 ||               ||     ||             ||
[17:15] <sconklin> In the last week, a security update was prepared and released.
[17:15] <sconklin> ..
[17:15] <bjf> [TOPIC] Incoming Bugs: Regressions (JFo)
[17:15] <MootBot> New Topic:  Incoming Bugs: Regressions (JFo)
[17:16] <JFo> Incoming Bugs
[17:16] <JFo>  19 Natty Bugs (up 7)
[17:16] <JFo>  1088 Maverick Bugs (up 26)
[17:16] <JFo>  1109 Lucid Bugs (up 21)
[17:16] <JFo> Current regression stats (broken down by release):
[17:16] <JFo> [17:16] <JFo> As this tag is deprecated, this listing is only to ensure that I keep it on my radar until
[17:16] <JFo> changes to the apport hooks and my processing of the currently tagged bugs is completed.
[17:16] <JFo>   * 1 natty bugs
[17:16] <JFo>   * 394 maverick bugs
[17:16] <JFo>   * 178 lucid bugs
[17:16] <JFo> [17:16] <JFo>   * 23 maverick bugs (up 3)
[17:16] <JFo>   * 81 lucid bugs (up 3)
[17:16] <JFo>   * 6 karmic bugs (no change)
[17:16] <JFo>   * 0 hardy bugs (no change)
[17:16] <JFo> [17:16] <JFo>   * 167 maverick bugs (up 11)
[17:16] <JFo>   * 199 lucid bugs (up 7)
[17:16] <JFo>   * 40 karmic bugs (no change)
[17:16] <JFo>   * 2 hardy bugs (no change)
[17:16] <JFo> [17:16] <JFo>   * 13 maverick bugs (no change)
[17:16] <JFo>   * 6 lucid bugs (no change)
[17:16] <JFo>   * 1 karmic bug (no change)
[17:16] <JFo> ..
[17:17] <bjf> [TOPIC] Triage Status (JFo)
[17:17] <MootBot> New Topic:  Triage Status (JFo)
[17:17] <JFo> The next bug day will be next Tuesday covering regression-update bugs. there are 118 bugs that need to
[17:17] <JFo> be looked at, the majority of which will need to be tested against the latest released version and the current version in
[17:17] <JFo> development. I'll send out an e-mail today concerning the day. I'll also post a blog post on our voices page.
[17:17] <JFo> whoops
[17:17] <JFo> wrong bit
[17:17] <JFo> The first iteration of the Bug List is running hourly. It is available:
[17:17] <JFo> http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
[17:17] <JFo> As always your feedback on it is much appreciated.
[17:17] <JFo> Bug Expiration seems to be working. I have seen several bugs Expired by the system recently. I am trying to work out how
[17:17] <JFo> to see what is being expired (number wise) versus what we would have expired with our arsenal script. This is mainly to see
[17:17] <MootBot> LINK received:  http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html
[17:17] <JFo> if the process is working as we expect so that I can provide that feedback to the LP team.
[17:17] <JFo> ..
[17:18] <bjf> [TOPIC] Incoming Bugs: Bug day report (JFo)
[17:18] <MootBot> New Topic:  Incoming Bugs: Bug day report (JFo)
[17:18] <JFo> see above :)
[17:18] <bjf> already covered ^^
[17:18] <JFo> ..
[17:18] <bjf> [TOPIC] Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:18] <MootBot> New Topic:  Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:19] <bjf> thanks everyone
[17:19] <bjf> #endmeeting
[17:19] <MootBot> Meeting finished at 11:19.
[17:19] <JFo> thanks bjf :)
[17:19] <apw> thanks
[17:19] <smb> thanks bjf
[17:19] <cking> thanks
[17:19] <kamal> thanks bjf
[17:19] <sconklin> thanks
[19:52] <YoBoY> toc toc
[19:52] <YoBoY> début de la réunion dans 8 minutes
[19:53] <YoBoY> oups sorry wrong channel ^^"