/srv/irclogs.ubuntu.com/2010/11/30/#ubuntu-meeting.txt

=== jjohansen is now known as jj-afk
=== Amaranth_ is now known as Amaranth
Agent007Ubuntu is pretty unworthy to be on my desktop05:01
=== jj-afk is now known as jjohansen
* persia wonders if it is one of those days10:02
nigelbpersia: wasn't it supposed to be last week?10:10
persiaYeah, but it wasn't, which makes me wonder if it's this week.  I think it isn't.10:13
nigelbI think I haven't seen an Asia meeting in Nov at all10:14
persiaOn the bright side, I don't think you've missed any :)10:15
nigelbpersia: lol10:21
=== elky is now known as melissa
=== melissa is now known as elky
* lifeless is epically confused10:57
nigelbpersia: heh, you should just start a meeting and action youself to remind the rest of the board members ;)11:01
nigelb@now11:02
ubottuCurrent time in Etc/UTC: November 30 2010, 11:02:2411:02
persiaToo late.  I'll do that next week if there isn't a meeting.11:02
nigelblifeless: 10 am.  London probably isn't UTC11:03
nigelbNo, it isn't.11:03
lifelesstoo late is a local phenomena11:04
nigelbheh11:04
RawChid#ubuntu-team11:29
=== jjohansen is now known as jj-afk
NCommander#startmeeting12:59
MootBotMeeting started at 06:59. The chair is NCommander.12:59
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]12:59
NCommander[link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/2010113012:59
MootBotLINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/2010113012:59
ogra_acbah12:59
NCommanderjust for the record, who's here?12:59
ogra_acyoure to early12:59
* janimo is here13:00
ogra_acadjust your clock !13:00
davidmhello13:00
ogra_acthat link doesnt match the one from the announcement :P13:00
NCommandermorning davidm13:00
NCommanderogra_ac: so I made a slight mistake13:00
NCommander[topic] Action Item Review13:01
MootBotNew Topic:  Action Item Review13:01
NCommander[topic] persia to handle namespace renaming13:01
MootBotNew Topic:  persia to handle namespace renaming13:01
* NCommander pokes persia 13:01
persiaUgh.  Editing the wrong page :(13:01
* rsalveti wonders when the announcement will bring the correct link hehe13:01
NCommanderrsalveti: I put a redirect on the link I sent by accident13:02
rsalvetiNCommander: ok, that wasn't there when I tried13:03
persiaCarry it over.  It's in-process (except at the wrong place :/ )13:03
NCommander[topic] persia and NCommander to work out new meeting announcement text13:03
MootBotNew Topic:  persia and NCommander to work out new meeting announcement text13:03
NCommanders/Mobile/ARM/g was really it13:04
persiaI think that was lost due to "Thanksgiving", or at least we didn't seem to be online at the same time much.13:04
persiaNo, we have to make it better :)13:04
NCommanderso c/o13:04
NCommander[topic] persia to make the bugsquad create a bug overview page for ubuntu-armel13:04
MootBotNew Topic:  persia to make the bugsquad create a bug overview page for ubuntu-armel13:04
persiaDidn'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 Items13:05
MootBotNew Topic:  Special Items13:05
NCommander[topic new meeting time13:05
NCommander[topic] new meeting time13:05
MootBotNew Topic:  new meeting time13:05
ogra_acNCommander, it was more than /Mobile/ARM13:05
ogra_ac(sigh)13:06
* ogra_ac wishes you wouldnt rush so fast13:06
persiaSo, I talked to lots of folk, and 15:00 Thursday seemed the least inconvenient.13:06
persiaWell, "lots" is really only about 10 people, but still :)13:07
ogra_acpersia, for the bugsquad page, just ping bdmurray13:07
NCommanderso 7 PST, 9 CST, 10 EST, and something over in Europe13:07
persiaIs anyone here now that wouldn't be able to make it then?13:07
persiaogra, I know, but Thanksgiving :)13:07
ogra_acit took him 30sec to change it to canonical-arm for us13:07
ogra_acok13:07
persiaYeah, just need overlap.  I expect I'll catch him beginning of his day today.13:07
rsalvetipersia: 15 utc?13:08
ogra_acNCommander, UTC times please13:08
persiarsalveti, Yes.13:08
rsalvetiI'm fine13:08
janimome too13:08
* ogra_ac too13:08
* NCommander will be with coffee13:08
persiaOK, so it will move to then, starting from 9th December.13:09
GrueMastercoffee not working at 5am PST.  Sorry.13:09
persiaBy the way, what's the team membership policy?13:09
NCommander[action] NCommander to annouce new time with Dec 9th meeting13:09
MootBotACTION received:  NCommander to annouce new time with Dec 9th meeting13:09
persiaJust ask an admin?13:09
ogra_acpersia, which team ?13:09
NCommanderpersia: requires a vote13:09
NCommanderor well13:09
NCommanderfor the mobile team it did13:09
NCommanderubuntu-armel I think is just add yourself13:10
ogra_acwhich team are we talking about ?13:10
persiaubuntu-armel13:10
ogra_acno, its moderated13:10
persiaYeah, what's the policy?13:10
ogra_acjust as an admin, yeah13:10
persiaThat's what I thought: just wanted to verify.13:10
ogra_acdo we want more admins ?13:10
* ogra_ac will happily add another13:11
* persia wants *NOT* to be an admin :)13:11
* NCommander could do it as I run the meeting and could add people who ask13:11
ogra_acwell, just to have a fallback13:11
ogra_acNCommander, ok, i'll add you after the meeting13:12
NCommanderthanks13:12
NCommander[topic] Standing Items13:12
MootBotNew Topic:  Standing Items13:12
NCommander[link] http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel.html13:12
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel.html13:12
NCommander[link] http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel-natty-alpha-1.html13:12
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel-natty-alpha-1.html13:12
ogra_acplease move your WIs to A213:14
ogra_acif you dont plan to get to them today13:14
* NCommander seconds ogra_ac's comments13:14
ogra_acwe look really really bad13:14
davidmMine are done or moved :-)13:14
NCommanderBTW, ogra_ac http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel-natty-alpha-2.html13:14
ogra_acGrueMaster, still has two A1 items13:14
NCommandercan you get THAT fixed13:14
GrueMasterIf they need to be done today, I'll move mine to A2.  Was planning on pushing out list this week.13:15
ogra_acNCommander, ask persia ;)13:15
ogra_acNCommander, he maintains that page13:16
NCommanderanyway13:16
ogra_aci care for canonical-arm only (and said so before we had the second page=13:16
NCommandercan I move on from burndown charts?13:16
ogra_acerm13:16
ogra_acwhere are the canonical-armel charts in your paste?13:16
* ogra_ac sighs and goes to the other page13:17
ogra_achttp://people.canonical.com/~pitti/workitems/natty/canonical-arm.html13:17
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-arm.html13:17
ogra_acwe're way over trendline here13:17
ogra_acso please work on your itmes :)13:18
NCommanderanyway13:18
NCommander[link] http://qa.ubuntu.com/reports/team-assigned/canonical-arm-assigned-bug-tasks.html13:18
MootBotLINK received:  http://qa.ubuntu.com/reports/team-assigned/canonical-arm-assigned-bug-tasks.html13:18
NCommanderI've made some work on mono and have some test cases that crash wonderfully13:19
NCommanderWill work on it some more, but its only a medium on my TODO13:19
NCommanderflash-kernel will get fixed as soon as I rebuild the XM's SD13:19
janimoNCommander: I can try to help with that if you brief me in13:19
janimomono I mean13:20
NCommanderjanimo: needs hardware unfortunately. As soon sa you have it, I'd be glad to have assistance :-)13:20
janimoah ok13:20
janimoso far I am poking around kakadu13:20
GrueMasterpersia: 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:20
NCommanderjanimo: 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 kakadu13:21
rsalvetidavidm: did you send the beagle to janimo?13:21
rsalvetiif so, janimo will probably get it in 2, 3 days13:21
janimoNCommander: which is the LP bug you are chasing?13:21
NCommanderjanimo: its the banshee bug which is actually mono13:21
janimoNCommander: I was under the impression that mono or related stuff FTBFS , not a runtime crash13:22
janimoah ok13:22
NCommanderjanimo: runtime crash annoying :-/13:22
janimoI see13:22
NCommandermono under ARM has always been a bit twichy13:23
NCommanderanyway, can I move on?13:23
janimoapparently did not work on maverick already13:23
janimosure13:23
ogra_acmove13:23
NCommander[topic] Kernel Status (cooloney)13:23
MootBotNew Topic:  Kernel Status (cooloney)13:23
ogra_acso we had some tests of linaros omap3 kernel i belive13:23
ogra_ac:)13:23
ogra_accooloney isnt here13:23
ogra_acso i'll summarize13:24
ogra_acit seems to work on rootstock images13:24
GrueMasterI just saw the note this morning to test it on XM.  Will try to get to it today.13:24
ogra_acrsalveti, offered to test on XM13:24
rsalvetisure, going on this today13:24
ogra_acso we see if jasper still does the right thing13:24
ogra_aconce thats done a config comparison has to happen13:24
rsalvetiI believe the only remaining thing for cooloney is to check and compare the config13:25
ogra_acif thats ok for us as well, the ball is on apw's table13:25
ogra_acto commit (or not) to SRU and security uploads13:25
rsalvetiyeah13:25
ogra_acs/apw/kernel-team/13:25
=== oubiwann is now known as oubiwann_
rsalvetiso we'll test, cooloney will check the config and the kernel team will give the proper ack13:26
rsalvetithen we can continue13:26
=== oubiwann is now known as oubiwann_
rsalvetino more for kernel I believe13:26
ogra_acright13:26
ogra_acthen we need MIRs etc13:27
ogra_acor one MIR13:27
rsalvetiyeah13:27
davidmrsalveti, beagle will go out today, was delayed13:27
rsalveticool :-)13:27
rsalvetiso I believe janimo will have a new toy to play even during weekend if he wants :-)13:28
=== oubiwann is now known as oubiwann_
janimogood :)13:28
ogra_aci cant judge the omap4 kernel13:28
ogra_acGrueMaster, did it work on the images from the 19th ?13:28
GrueMasterNo.  I have a note in my QA update.13:29
ogra_ack13:29
ogra_acso lets move on13:29
ogra_acNCommander,13:29
NCommander[topic] QA Status (GrueMaster)13:29
MootBotNew Topic:  QA Status (GrueMaster)13:29
GrueMasterCurrently seeing issues with Maverick kernel updates on panda.  Base image works fine.  Once kernel is updated, no monitor output is visible.13:29
GrueMasterLast 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
GrueMasterWill 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 panda13:30
GrueMasterThese are the issues I am currently dealing with.13:30
ogra_acand has still fine display output13:30
* rsalveti too13:30
rsalvetiprobably an issue with the new monitor GrueMaster got13:30
ogra_acyeah13:30
ogra_acdont buy dell ;)13:30
ogra_acwe know there are issues with their EDID13:31
GrueMasterOn 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_acah13:31
ogra_acintresting13:31
rsalvetithat's weird, works fine for me13:31
GrueMasterBTW:  Dell monitor worked fine on released image.13:31
ogra_acdid you modify boot.scr in any way ?13:31
rsalvetiand there wasn't any change that affect the video13:31
ogra_acyeah13:31
GrueMasterNot until I started seeing issues.13:31
ogra_acworks fine here too wiht a default image upgraded across all -updates/-security kernels13:32
rsalvetianyway, needs further debugging13:32
ogra_acright13:32
ogra_acanything else for QA ?13:32
GrueMasterYes, I plan on doing more testing today.  I was distracted yesterday with other issues.13:32
GrueMasterNone other than what I posted above.13:33
ogra_acNCommander,13:33
NCommander[topic] ARM Porting/FTBFS status (NCommander)13:33
MootBotNew Topic:  ARM Porting/FTBFS status (NCommander)13:33
ogra_acshould have janimo in the brackets too ;)13:33
NCommanderApplied a patch today to work around KDE being FTBFS so libproxy woul dbuild getting us closer to A1 images13:33
NCommandertransmission was deseeded on ARM for a similar reason13:33
* ogra_ac gave back a good bunch of packages yesterday13:34
NCommanderboth changes will be reverted past A113:34
ogra_acmost of tehm survived the build13:34
NCommanderlooks like we're on track for A1 images. A team first I might add13:34
ogra_acwell, we'll see (more in the image section=13:34
rsalvetiNCommander: I believe we just need a bug to revert this after a113:34
ogra_ac)13:34
rsalvetias lool pointed out at the bug13:34
ogra_acyeah, lool asked for one13:35
=== doko_ is now known as doko
ogra_acand it makes sense so we dont forget13:35
NCommanderrsalveti: I'm just going to reopen the bug that we used to revert13:35
rsalvetiyeah13:35
ogra_ac(though i guess ScottK would complain anyway) ;)13:35
ogra_acthat u! doesnt work on kubuntu arm13:35
ogra_ac*U113:35
ScottKNo  I consider that a feature.13:35
ogra_aclol13:36
rsalveti:-)13:36
ogra_acScottK, what if i switched to kubuntu now ?13:36
rsalveticurrently? boom13:36
ogra_aci would complain loudly that i cant use my U1 purchased music13:36
ogra_ac:)13:36
ScottKYou'd want a different architecture thanks to gcc "improvements"13:37
NCommanderogra_ac: at least you can use the U1 music store13:37
ogra_ac(well, not using natty in production indeed)13:37
NCommanderKubuntu users can't without firing up GNOME last time I tried13:37
ScottKThe regular U1 client works fine as I understand it.13:37
NCommanderbut this is completely off-topic13:37
ogra_achmm, right13:37
ogra_acanyway, seems thats it for ftbfs13:37
NCommander[topic] ARM Image Status (ogra, NCommander)13:38
MootBotNew Topic:  ARM Image Status (ogra, NCommander)13:38
ogra_acbad13:38
ogra_acbroken13:38
ogra_acetc etc13:38
rsalveti:-)13:38
ogra_acNCommander, and i sorted most of the obvious blockers13:38
ogra_acbut we dont know if there are subsequent ones yet13:38
ogra_aci will fire off a testbuild after the meeting13:39
ogra_acso we can see13:39
rsalvetioh, ok13:39
ogra_acshould be usable for A1 i hope13:39
ogra_acbut there are more things omn the ftbfs list13:39
rsalvetiwhat is the fix date limit, today?13:39
ogra_acrsalveti, thu is A1 release date13:40
ogra_acas long as we have booting images by then its fine13:40
rsalveticool13:40
ogra_acA1 criteria is "bootable"13:40
ogra_aceverythig else is nice to have13:40
rsalvetigot it13:40
ogra_acoh13:40
ogra_acand we obviously dont build omap3 images until the kernel is there13:40
NCommanderI think that's everything13:41
NCommandercan we move on?13:41
ogra_acsince the old one is gone13:41
ogra_acmove13:41
rsalvetisure, np13:41
NCommander[topic] Any Other Business13:41
MootBotNew Topic:  Any Other Business13:41
* ogra_ac has something ...13:41
NCommanderI'd like to tka ea moment to introduce james_w13:41
NCommanderer13:41
NCommanderdamn it13:41
ogra_aclol13:41
ogra_achello james_w13:41
ogra_ac:P13:41
rsalvetianother new team member?13:41
NCommanderjanimo:13:41
ogra_acNCommander, nice that you introduce him13:41
janimohello all13:41
davidmjanimo, welcome13:42
ogra_achey janimo, welcome to the team13:42
rsalvetiyeah :-)13:42
rsalvetihopefully you'll like it13:42
janimothanks. Any other tasks besides FTBFS that I should start looking into?13:42
janimoHow are work items assgined?13:42
janimoI hope so too :)13:42
NCommanderjanimo: the meaning of life, the universe, and everything?13:42
ogra_acjanimo, 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 you13:42
rsalvetiyeah, better13:42
ogra_acand let us know so we can assign them to you13:43
janimoI see quite a few that are interesting13:43
rsalvetijanimo: what you generally like to work with?13:43
janimobut not sure how much involved other memebers are already in them13:43
ogra_acjanimo, so best is to contact the asignee and have him assign items to you13:43
janimorsalveti: once I have hardware as well, things which are close to hw are fine13:43
rsalvetisee what you'd like to help with, poke the original target member and see13:43
janimoI see some of the WIs are assigned to members outside the ARM team13:43
rsalvetijanimo: cool13:44
janimosuch as 'make lightspark build on ARM'13:44
ogra_acfeel free to take that over from stgraber13:44
janimook13:44
ogra_aci worked on it with him already13:44
ogra_acand the prob is that lightspark uses a lot of intel SSE assembler13:45
ogra_acthat needs to be rewritten completely for arm13:45
janimoyep, just read that13:45
janimoso not just a pacvkaging task13:45
ogra_acwhich neither of stgraber or me will have time to do13:45
ogra_aci have packaging fixes13:45
janimoI can look at that even if it sounds quite a large task13:45
ogra_aci can get it build up to a point where it gets to the asm stuff13:45
ogra_acbut indeed not beyond13:46
janimowhat 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
rsalvetijanimo: generally over uds13:46
janimobut 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 on13:46
ogra_achttp://people.canonical.com/~pitti/workitems/natty/canonical-arm.html has all WIs we are intrested in from a canonical-arm POV13:46
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-arm.html has all WIs we are intrested in from a canonical-arm POV13:46
rsalvetiduring the discussion of the bp13:46
ogra_acthe wider community view should be on http://people.canonical.com/~pitti/workitems/natty/ubuntu-armel.html13:47
janimobut canonical-arm is the priority?13:47
ogra_acNCommander, can you please remove the *pitti from the links in the wiki ?13:47
rsalvetijanimo: also starts following linaro13:47
ogra_acjanimo, for canonical work stuff, yeah13:47
NCommanderogra_ac: k13:47
ogra_acNCommander, that has to be ~platform13:48
NCommander[action] NCommander to fix workitem links13:48
MootBotACTION received:  NCommander to fix workitem links13:48
davidmjanimo, yes for canonical work stuff13:48
rsalvetijoin #linaro, linaro's m-l and etc, we generally have overlap with them13:48
ogra_acthey have packages they care about which we usually only rarely touch (i.e. toolchain)13:48
ogra_acand they have different requirements13:48
ogra_acso talking to them usually makes sense13:49
NCommanderogra_ac: I think we should take this to another channel TBH13:49
NCommanderI'm ready to close out the meeting13:49
* ogra_ac still has an item :P13:49
janimook. Especially since some FTBFS have toolchain implications13:49
rsalvetijanimo: yeah13:49
rsalvetiogra: move on13:49
ogra_acright, talk to linaro, they have good toolchain experts13:49
ogra_acwell, i'm on vacation from monday on til end of the year13:49
ogra_achaving to burn all my vacation days13:50
ogra_aci will likely still be online on IRC here and there13:50
ogra_acbut dont ask me about work :P13:50
rsalvetiogra_ac: cool, enjoy :-)13:50
rsalvetifound anywhere to travel already?13:50
GrueMasterwe never do.  :P13:50
janimoogra_ac: have a relaxing time!13:50
ogra_aci only need to collect some miles, will likely just do a one day flight to some far but cheap place13:51
janimoiceland?13:51
ogra_acbeyond that i will care for my house13:51
ogra_acjanimo, to close sadly13:51
* NCommander is glad to know he's not the only one flying on occession for status :-)13:51
ogra_aci considered it ;)13:51
NCommanderThe joys of mileage running13:51
janimoogra_ac: not if you go via mumbai13:51
ogra_acNCommander, i wont do that twice in my life13:51
ogra_acjanimo, but then it gets to expensive ;)13:51
ogra_acmumbai was also on the list btw ;)13:52
janimomoscow?13:52
ogra_acbut anyway, lets not get to much off topic13:52
ogra_acto close again ;)13:52
rsalveti:-)13:52
janimook13:52
rsalvetiany other topics?13:52
ogra_ac(and to cold)13:52
* ogra_ac has nothing13:52
janimoso I'll probably start asking team members if they want to pass me some WIs13:52
ogra_acyeah, do that13:52
janimoso I can do some more focused work for alpha213:52
ogra_acwe didnt really have much for A113:53
janimobut you can also start telling me about WIs you could use help with13:53
ogra_acindeed13:53
NCommanderOk, I'm going to close the meetin gout just caue we're going offtopic13:53
NCommanderjanimo: ogra_ac: lets move this to ubuntu-arm13:54
NCommanderClosing in 313:54
NCommander213:54
NCommander113:54
NCommander#endmeeting13:54
MootBotMeeting finished at 07:54.13:54
=== yofel_ is now known as yofel
=== freeflyi1g is now known as freeflying
=== SuperHark is now known as MichealH
mdzcjwatson, kees, Keybuk, pitti, sabdfl: ping14:59
mdz#startmeeting14:59
MootBotMeeting started at 08:59. The chair is mdz.14:59
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]14:59
pittihello15:00
mdz[topic] Action review15:00
MootBotNew Topic:  Action review15:00
mdz[link] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000784.html15:00
MootBotLINK received:  https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-November/000784.html15:00
mdzI missed the previous meeting, so please correct me if I've missed anything15:01
pittiKDE microversion SRU docs has happened15:01
mdzit looks like there were no actions per se, though there were a couple of things which should be back on the agenda for this meeting15:01
mdzcouchdb & U1 on 10.0415:02
pittiright, the couchdb SRU and post-maverick updates15:02
mdzpitti: what is the status of the ARB exception proposal?15:02
pittiit was discussed a bit after the last meeting, but I didn't see much news there15:02
mdzok15:02
pittiit sounded like 90% of an agreement15:02
wendarwe ran out of time15:02
mdzis Chipaca around?15:02
pittihey wendar15:03
wendarhi pitti15:03
mdzhi Chipaca15:03
Chipacahi mdz15:03
wendarI've got a reply in the moderation queue again, if someone could give it a push before we get to that point in the agenda15:03
mdz[link] https://wiki.ubuntu.com/TechnicalBoardAgenda15:03
MootBotLINK received:  https://wiki.ubuntu.com/TechnicalBoardAgenda15:03
mdzwendar: there are no messages in the moderation queue for technical-board15:04
pittiwendar: ah, your reply just hit the list15:04
mdz[topic] couchdb lucid backport SRU - John Lenton15:04
MootBotNew Topic:  couchdb lucid backport SRU - John Lenton15:04
mdzso I missed the previous meeting, but have talked with Chipaca a little bit out of band15:04
pittithat was also discussed on the TB ML15:05
pittiwith some updates from yesterday/today15:05
mdzaccording to the minutes, the TB proposed an alternative solution and asked the U1 team to evaluate it15:05
mdzah, I hadn't read the latest15:05
mdzpitti: would you like to guide the discussion?15:05
pittithe alternative solution was proposed to ship a separate couchdb-1.0 package in lucid-updates15:05
pittimdz: yes, can do15:06
pittihello Chipaca15:06
ChipacaI 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.html15:06
MootBotLINK received:  https://lists.ubuntu.com/archives/technical-board/2010-November/000590.html15:06
mdzis the latest from Chipaca on the mailing list15:06
pittiright, and https://lists.ubuntu.com/archives/technical-board/2010-November/000592.html my latest reply15:07
mdzso Chipaca is saying that it's not feasible, from the sound of it15:09
pittiI'm interested in why15:09
Chipacahi, back15:09
mdz * while we can introduce a couchdb-1.0-bin package into 10.04 to15:09
mdz   address this issue, we can't really make it co-exist on the same15:09
mdz   machine wiht a 0.10 couchdb-bin, so it would have to conflict with15:09
mdz   it; additionally, we'd have to get a SRU for a client package in15:09
mdz   10.04 (either desktopcouch or ubuntuone-client would work) so that15:09
mdz   the 1.0 package gets pulled in, and an additional SRU for 10.10 to15:09
mdz   get the dependency fixed.15:09
pittiwhen 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 features15:10
mdzpitti, I believe you questioned the co-existence point15:10
pittiright, I'm curious why it wouldn't work15:10
mdzI'm inferring from Chipaca's tone that perhaps it just seems like too much work15:10
Chipacait 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 couch15:11
pittiand AFAIK it doesn't auto-migrate existing databases over to the 1.0 format, right?15:11
Chipacacouchdb auto-migrates, yes15:12
Chipacathe way we're shipping the system couchdb explicitly avoids the auto-migration15:12
Chipacaby adding the version number to the path to the database15:12
pittiso this would help making both co-installable15:13
Chipacawhat does co-installation try to fix?15:14
mdzChipaca: it seems like decoupling desktopcouch from the system-wide couchdb might be a good long-term move15:14
mdzit would enable you to update "your" couchdb without risking breakage in other couchdb applications15:15
pittiChipaca: not breaking the database API for existing insallations15:15
mdzChipaca: otherwise we will surely face exactly this same choice the next time you want to update15:16
mdzdo you need help getting the packaging right?15:16
mdzor do you feel this is not the best solution?15:17
Chipacathe 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 desktopcouch15:17
pittiif we can auto-migrate user databases, then we could switch desktopcouch to use 1.0?15:17
pittias far as I remember, the desktopcouch API wouldn't change15:18
Chipacaright, we'd update the desktopcouch package to depend on 1.0, and then we'd have to make desktopcouch start 1.015:19
mdzChipaca: I guess I don't understand why that's hard15:19
pittiand don't we need to do that either way?15:20
pittiadapting desktopcouch to start 1.0, I mean15:20
mdzstart_local_couchdb.py seems pretty straightforward15:20
thisfredpitti: well not if it were the only couchdb :)15:20
thisfredmdz, not super hard, it just means an extra SRU15:20
mdzit looks like it will already DTRT if the COUCHDB environment variable is set to an alternative binary15:20
thisfredwhich I don't think we'll get around anyway15:20
Chipacaand modifying desktopcouch in that sru in a way that won't be as tested as what we're replacing15:21
mdzthisfred: an extra compared to what?15:21
mdzsurely desktopcouch needs to be updated anyway15:21
Chipacathe difference is between updating just the packaging, and updating the code also15:21
thisfredmdz, it would not if we updated the system couchdb15:21
thisfredwhich I know we won't15:21
mdzthisfred: so if a 10.04 system gets couchdb updated to 1.0, the broken bits of U1 start working with no other changes?15:22
thisfredyep15:23
Chipacapitti: 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:23
pittiwell, it's not the lines of code that we change15:24
pittiby that measure, introducing a new package would be way off scale15:24
pittiit's about the greatest possible damage we can do to existing working setups15:24
pittiChipaca: if we make the packages conflict, then we couldn't pull in couchdb-1.0 automatically during upgrade15:25
pittisince couchdb is already installed15:25
pittiand the entire exercise would be moot, wouldn't it?15:25
mdzpitti++15:25
mdzit's about risk15:25
rickspencer3may I offer my opinion?15:25
mdzof course15:25
rickspencer3(even if people won't like it?)15:25
pittiand we can't just force-remove couchdb15:25
pittirickspencer3: please15:25
rickspencer3My view is that CouchDB missed the Lucid the train15:25
rickspencer3I understand this is painful as we would like to provide services to Lucid users15:26
rickspencer3However, I feel this effort is now misdirected15:26
mdzI 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 it15:27
thisfredI respectfully disagree, I think the side-by-side solution is still worth the (little extra) effort, if the TB approves it15:27
mdzbut it will be up to the U1 team whether that effort would be well spent15:27
rickspencer3it's not just effort on their part15:27
pittiright, with pretty much parallel packages15:27
thisfredpitti: yep15:28
rickspencer3this will cause effort to be expended across the organization15:28
mdzit may be that effort would be better invested in making the changes in natty such that we can issue future updates without a problem15:28
rickspencer3and Chipaca already said they lack the resources themselves to do proper packaging15:28
pittithisfred: 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 it15:28
mdzI'm with pitti15:28
rickspencer3well, I don't think it's worth the risk or the effort15:29
pittibut yes, mdz raises a good point -- we should make sure that if this happens again we are better prepared15:29
rickspencer3and the effort is not just on the U1 team15:29
pittiperhaps we should have a separate desktopdouch-server package which just talks to desktopcouch, and not use the "official" couchdb package at all15:29
mdzrickspencer3: fair point, there is other effort involved which perhaps we haven't included in our implicit estimate15:29
mdzI'm not prepared to offer the U1 team advice on whether this is worth it or not, at least not with my TB hat on15:30
mdzbut they are welcome to ask me for my Canonical opinion separately15:30
rickspencer3mdz, well, with my Director of Engineering hat on, I feel I should offer my views15:30
thisfredjust as a thought experiment, if we were to put couchdb 1.0 in backports15:30
thisfredwould that be acceptable?15:30
pittiyes IMHO15:30
rickspencer3isn't that specifically what backports if for?15:31
pittiwe make no promises wrt. API stability in backports15:31
Chipacabackports are not enabled by default, right?15:31
pitticorrect15:31
Chipacaok15:31
mdzI 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 whole15:31
pittiwhich is why we can be liberal there15:31
thisfredOf course most people using lucid for stability reasons won't have backports on...15:31
mdzrickspencer3: you absolutely should. I'm just explaining why I'm neither agreeing nor disagreeing with you :-)15:31
pittithisfred: so people who care about U1 syncing, and don't need existing couchdb could just grab it from backports, you mean?15:31
rickspencer3right15:31
thisfredpitti: yeah15:32
mdzcouchdb 1.0 in backports is OK with me as well, and I expect the backports team would be amenable15:32
thisfredpitti: though the downside is that they'd have to be made aware of this15:32
pittiit would mean backports of couchdb and desktopcouch; anything else?15:32
mdzthisfred: it would also entail testing both upgrade paths, if you want to support those users properly15:32
thisfredpitti: nope, and not even desktopcouch if we don't do the parallel install there15:32
aquariusthisfred, couch 1.0 doesn't need a newer spidermonkey?15:33
pittithisfred: lucid's desktopcouch doesn't need updates to talk to an 1.0 couchdb API? that did change15:33
thisfredpitti: no, the API (that desktopcouch cares about) did not change between 0.10 and 1.015:34
pittithisfred: 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 backports15:34
thisfredpitti: we'd only need to make changes to d-c if we were to have the parallel install15:34
pittithisfred: 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
mdzoption 1: parallel package couchdb 1.0, update desktopcouch to use it, and release via SRU exception15:35
mdzoption 2: parallel package couchdb 1.0, update desktopcouch to use it, and release via backports15:35
thisfredaquarius: 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 route15:35
Chipacaoh, I was reading option 2 as non-parallel15:36
mdzoption 3: update couchdb to 1.0 in backports, superseding 0.1 in lucid15:36
pittimdz: I think option 2 is "backport maverick couchdb", no parallel install, right?15:36
Chipacaah15:36
pittiah, right15:36
Chipacait's 0.10, not 0.1 :)15:36
mdzChipaca: sorry15:36
mdzs/0.1/0.10/15:36
pittiI think we can rule out 215:36
pittiit's almost as much effort as 1 but a lot less benefit15:36
thisfredright15:36
mdzok15:36
rickspencer3mdz is there not an option to simply move on?15:36
Chipacaand about the sru of the control panel to alert users of the availability of the fix, is tehre agreement on that?15:37
mdzoption 4: do nothing, focus on natty, move on15:37
mdzrickspencer3: yes!15:37
rickspencer3:)15:37
mdzany other options?15:37
Chipacamdz: does option 2 include the ubuntuone-preferences sru to alert users of the issue?15:37
Chipacaum, option 3 i meant15:38
pittimdz's option list seems complete to me15: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
mdzChipaca: I'm not familiar with that idea15:38
aquarius(er, s/backport/SRU/, sorry)15:38
Chipaca<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 backports15:38
Chipacamdz: ^15:38
=== dholbach_ is now known as dholbach
rickspencer3wow15:38
pittiaquarius: I'd vote against it, so you'd need to convince another majority of the TB15:39
aquariuspitti, just making sure the option list is complete. :)15:39
mdzaquarius: I'm with pitti15:39
pittiaquarius: but yes, it'd complete the option list15:39
mdzChipaca: thinking15:40
rickspencer3well, I guess there are options that the TB would accept, and then options that Ubuntu Engineering would be willing to support with resources15:40
rickspencer3that list may not be the same15:40
mdzso 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
mdzI think that could be done in a way that would be acceptable to the SRU team15:41
pittior skip the web page and try to come up with a short text15:42
mdzany objections to dropping option 2 because it's dominated by the others?15:42
thisfredmdz +1 on dropping 2.15:43
mdzdone15:43
mdzoption 1: parallel package couchdb 1.0, update desktopcouch to use it, and release via SRU exception15:43
mdzoption 3: update couchdb to 1.0 in backports, superseding 0.1 in lucid15:43
mdzoption 4: do nothing, focus on natty, move on15:43
pittimdz: +1 on dropping 215:43
pittithisfred, aquarius: hm, we could even check if there are local systemwide couchdbs15:43
pittiand only show that note if there aren't15:44
mdzbenefits of 1: might make future updates easier15:44
mdzcosts of 1: relatively large development and testing effort15:44
mdzbenefits of 3: relatively small development and testing effort15:44
aquariuspitti, 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
pitti1 sounds like a good future path from natty on (i. e. have a desktopcouch-private couchdb server package)15:44
mdzbenefits of 3: zero impact to users who do not use U115:44
pittiaquarius: could be; that, or checking the data dir15:45
mdzdisadvantages of 3: more fiddly for users who do use U115:45
pittimdz: "... want to use more features of U1"15:45
mdzpitti: ack15:45
mdzbenefits of 4: zero development and testing effort, strong focus on current development and forward momentum15:46
mdzdisadvantage of 4: disappoint people who want the new features on LTS15:46
mdzwhat else have I missed?15:46
aquariusmdz: "...who want the *existing* features on LTS"15:46
Chipacaanother disadvantage of 4: for a non-ignorable number of people, ubuntu one will (continue to be) "just file sync"15:47
mdzaquarius: did they actually lose features they had when 10.04 came out?15:47
pittimdz: thanks for summarizing; looks complete to me15:47
Chipacamdz: yes, the features worked on release15:47
Chipacamdz: and then buckled under load15:47
mdzok, so we had to regress them in order to get it working for anybody15:48
rickspencer3well, it worked on the client, but from the users point of view, it did not work15:48
mdzand they probably didn't use it for very long15:48
mdzin effect, it shipped without the functionality, no?15:48
mdzit = 10.0415:48
rickspencer3in effect15:48
mdzis there anything more for the TB to decide?15:49
rickspencer3you could/can store data in couchdb, but there is no syncing and it fails silently15:49
thisfredin effect yes, as we had to disable replication on the server very soon after release15:49
Chipacai disagree with rickspencer3, but I know we disagree15:49
mdzwe'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 energy15:50
pittiwith my TB hat on, I'd approve any of 1, 3, 415:50
pittiwith my developer hat on, I think we should at least do 315:50
mdzwe have another item on the agenda which wendar has been waiting patiently to discuss15:50
pittithen clean up the situation in natty (with an approach like 1)15:50
pittiand then perhaps reconsider later on if this can be backported15:50
Chipacamdz: to make things clear, we decide which way forward is best, and the TB approves of it?15:51
Chipacaof these options15:51
pittisounds fine15:52
pittiChipaca: but it seems you can do any of above option, and it'd get the TB's approval15:52
mdzChipaca: yes, pretty much. I think we need some oversight on the details if it's 1 or 315:52
mdzso we should stay in touch15:52
mdzbut you would have our blessing15:52
Chipacaok, thank you15:53
mdz[topic] ARB exception proposal - Allison Randal15:53
MootBotNew Topic:  ARB exception proposal - Allison Randal15:53
mdzwendar, thanks for your patience15:53
wendarIIRC, there's another meeting here on the hour. A quick summary:15:53
wendar- Allow .desktop files to be installed outside /opt.15:53
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:54
pitti(for the record, natty's cdbs/quickly/etc. already support this)15:55
wendarThe 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
persiaWhy except .desktop files: couldn't they be pulled by extending DefaultAppDirs in some package in extras upon which things depend?15:55
wendarpersia: no part of the system knows how to pull .desktop files from non-standard paths15:56
mdzwendar: I'm a bit concerned on behalf of the ARB about the expectation that they will fix up the packages as needed15:56
wendarpersia: we can modify it for Natty, but not for Maverick15:56
mdzbut I guess you can speak for yourselves on that point?15:56
wendarmdz: yes, that manual work is not something we could do for the long-term, but for Maverick we have few submissions15:57
wendarmdz: only 4 at the moment15:57
persiawendar, The menu-xdg package has an implementation that pulls from /var/lib/menu-xdg/applications/menu-xdg15:57
pittipersia: can you extend the .desktop search path with an extra conffile?15:57
persiapitti, Yep.15:57
pitti(I know, *I* ought to know this, but I don't, sorry)15:57
persiaWell, I should say you *could*.  I haven't dug deeply in menus for > 18 months.15:58
mdzwendar: binaries only in /opt = "binaries nowhere else but in /opt", not "nothing in /opt which is not a binary", right?15:58
wendarpersia: 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
pittibut my concern is that this would need modification of gnome-menus, the KDE counterpart, and any other desktop env15:58
persiawendar, I believe so, but it would take me a few hours to chase the how.15:58
pittimdz: confirmed; it's "no files outside /opt", except perhaps .desktop15:59
wendarpitti: yes15:59
mdzthe .pyc and symlink stuff is definitely OK by me16:00
mdzif the ARB is ok with fixing up the packages, I'm OK with t hat too16:00
mdzno-binaries-outside-of-/opt seems sensible enough16:00
mdzthe extras.ubuntu.com path also sounds fine16:00
mdzso the only question is about how to handle .desktop files?16:00
wendaryes, just .desktop16:01
mdzI don't know how many programs use /usr/share/applications16:01
wendarand, whether to use the path /opt/extras.ubuntu.com/16:01
mdzbut AIUI the standardized interface is the filesystem16:01
persiamdz, ~90%, and everything with a menu entry uses that or a subdirectory.16:01
wendarmdz: the intention is that most of these apps will be using .desktop files16:01
mdzis it not workable to install the .desktop files in /opt and symlink them to /usr?16:01
wendarmdz: yes, a symlink would be workable16:02
mdzpersia: I meant, how many programs *read* the list of .desktop files16:02
wendarmdz: it would still pollute the general namespace, but preserves the principle of "install in /opt"16:02
mdzwendar: a symlink would at least give correct behavior if the stuff in /opt went away16:02
persiaOh.  Six, last I counted (7.10)16:02
mdzbut if that's managed by the package manager, I don't suppose that's a problem16:02
pittiI don't see much difference between symlink and actually installing into /u/s/a/, but symlink sounds fine16:03
mdzI'm happy either way16:03
mdzpitti: I was thinking of opt as something which is managed outside of the package manager, but in this case of course it isn 't16:03
wendarokay, so approved a symlink for .desktop files outside /opt?16:03
mdzI was worried about dangling .deskto pfiles16:03
pittiwendar: would be interesting to investigate enlarging the search path in natty16:03
wendarand I'll work with persia to see if we can get actual load from /opt working16:03
pittito pick up desktop files in /opt16:03
mdzwendar: I think it's unnecessary complexity, installing directly in /usr should be OK16:03
mdz(installing .desktop files in /usr, I mean, of course)16:04
pitti^ especially since these get manual review for sanity16:04
persiawendar, 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
wendarthen, approved to install .desktop files in /opt, if we can't find a workaround for Maverick16:04
wendarfor Natty, we should have .desktop files in /opt working16:04
mdzwe don't actually have a quorum of the TB here, I don't think16:04
pittiwendar: you mean "approved .. in /usr/s/apps/"16:04
mdzso if you need an official vote or something, we'll have to take it to email16:04
wendarpitti: aye16:05
mdzbut it sounds sane to me16:05
pittibut that has already been brought up on the list without opposition16:05
mdzwe need to clear out to let the server team have their meeting16:05
pittigreat16:05
wendarthen, last thing: /opt/extras.ubuntu.com/?16:05
pitti+1 (as I said on the ML)16:05
mdzwendar: I said +1 above as well16:05
mdzdone?16:06
wendardone, thanks!16:06
mdzI don't see anything else on the mailing list16:06
mdzso that's a wrap, thanks all16:06
mdz#endmeeting16:06
MootBotMeeting finished at 10:06.16:06
pittithanks all16:06
hggdh~ô~16:06
Daviey\o/16:06
JamesPageo/16:06
hallyn_\o16:06
JamesPagelooks like most folk are here so lets make a start16:07
robbiew*\o/*16:07
JamesPage#startmeeting16:07
MootBotMeeting started at 10:07. The chair is JamesPage.16:07
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]16:07
kirklando/16:07
jj-afk\o16:07
=== jj-afk is now known as jjohansen
JamesPage[TOPIC] Review ACTION points from previous meeting16:07
MootBotNew Topic:  Review ACTION points from previous meeting16:07
JamesPageALL: please check the SRU tracker https://wiki.ubuntu.com/ServerTeam/SRUTracker and help out with verification16:07
ttxo/16:07
JamesPageso hows that going for everyone?16:08
hggdh\life is good, and Hudson kicks16:08
zulhi16:08
DavieyJamesPage: pretty good!16:08
hallyn_JamesPage: well, so i'm still not 100% clear on what we do with those16:09
hallyn_do we set up an environment to test the fix in, so we can comment 'fix works'?16:10
zulumm...that page is really really old16:10
JamesPagezul: do you have a more up-to-date view...16:10
hallyn_robbiew had given us one16:10
hallyn_i wonder if i pasted the wrong link two weeks ago into the action16:11
zulJamesPage: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html16:11
hallyn_i thought that one was old too16:11
zulhallyn_: nope thats the latest and greatest as of this morning16:11
JamesPageIs the concern the size of the 'unassigned bugs' list?16:11
SpamapSo/16:12
SpamapSthis time stinks for me btw.16:12
SpamapSJamesPage: the concern is actually the verification needed bugs16:12
JamesPageSpamapS: right - I think that answers the question16:13
hallyn_does it?16:13
JamesPageSo its about testing SRU's which are in -proposed and need to be verified (only four at the moment)16:14
robbiewthe verification needed bugs list is short, right?16:14
SpamapSJamesPage: 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
DavieyI think this requires a whole agenda item.... "SRU:  What it means to us ":)16:14
hallyn_but, failing that, we set up a hardy image or whatever and d oit?16:15
hggdhd oit?16:15
SpamapShallyn_: no the idea is to have somebody who is not the submitter test16:15
Davieyhallyn_: The release / QA team are currently discussing a best pratice for verification16:15
zulSpamapS: compared to the unassigned bugs and assigned bugs 4 is not alot16:15
SpamapShggdh: its french for "get 'er done"16:16
Davieyit 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 keys16:16
hggdhheh16:16
JamesPageOK before we get to bogged down in this16:17
hallyn_Daviey: ok16:17
JamesPageThe immediate focus is to verify the 'needs-verification' bugs16:17
JamesPageSpamapS: we carried this over from last weeks meeting as you where due to submit a proposal16:17
JamesPageI suggest we carry again until this is agreed and try to put some immediate focus on the current list.16:18
Daviey+116:18
SpamapSAgreed, 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' bugs16:18
MootBotACTION received:  ALL: please check the SRU tracker http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html for 'needs-verification' bugs16:18
JamesPagerobbiew to review /ServerTeam wiki16:19
hggdh+1 -- it might be a good thing to go on over the unassigned list and (perhaps) clean it up16:19
SpamapShggdh: I think its probably time to start marking dapper bugs Won't Fix16:20
hggdhSpamapS: it might. But we need a clear ack from management16:20
robbiewyeah....that's a todo for this week...the f*$#ing wiki!!! lol16:20
SpamapSI thought in the final year it was "security only" ?16:20
JamesPageok carried forward16:20
zulSpamapS: desktop i think16:20
JamesPage[ACTION] robbiew to review ServerTeam wiki16:21
MootBotACTION received:  robbiew to review ServerTeam wiki16:21
* SpamapS has no idea where or even if thats written down16:21
Davieydefacto :)16:21
JamesPageSpamapS to email a concrete proposal for addressing SRU verification backlog16:21
SpamapSJamesPage: right, same thing, carry to next week16:21
* SpamapS will send it RSN16:21
JamesPage[ACTION] SpamapS to email a concrete proposal for addressing SRU verification backlog16:22
MootBotACTION received:  SpamapS to email a concrete proposal for addressing SRU verification backlog16:22
JamesPageNext: Kernel team to follow up on EC2 status16:22
Davieysmb / jjohansen ?16:23
jjohansenhave done some testing with Bug #66949616:23
ubottuLaunchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro" [Critical,Confirmed] https://launchpad.net/bugs/66949616:23
jjohansenand we may have a solution, but it needs more testing first16:24
Daviey\o/16:24
jjohanseniscsi target has a newer version being built in dkms so we are planning to drop it for the kernel proper16:25
Davieyjjohansen: Is the kernel team testing that, or is it smoser ?16:25
jjohansenDaviey: I have been playing with it, and once we verify we will hand over to smoser to test16:25
Davieyrocking16:25
jjohansenI just don't trust my results from yesterday :)16:26
Davieyjjohansen: Is it likely to be resolved before thursday (if your fix works) ?16:26
jjohansenhrmmm, maybe16:26
smoseroh hey.16:26
=== kim0_ is now known as kim0
jjohansenthat is we can submit the fix (assuming I get the same results)16:27
jjohansenbut it maybe to late for the kernel already16:27
Davieyjust wondering if we are likely to see the fix in Alpha 1 release.16:27
smoserjjohansen, i'll bother you outside of meeting, i had accepted there would be no i386 amis for alpha116:27
jjohansengenerally kernel fixes need to be in a week before other stuff16:27
smoserbut i surely would be grateful if it happened to work16:28
jjohansenwell I booted a couple i386 amis last night16:28
Daviey\o/16:28
JamesPageOK so anything else for the Kernel team on ec2 status for natty?16:29
smoserif it is low risk to other things, i would say go for it.16:29
jjohansensmoser: well its sort of low risk, it involves turning off pv-on-hvm16:29
smoseryuck16:30
jjohansenyeah16:30
JamesPageNext ACTION to review: Kernel team to follow up on bug 66129416:30
ubottuLaunchpad bug 661294 in linux (Ubuntu) "System lock-up when receiving large files (big data amount) from NFS server" [Medium,Confirmed] https://launchpad.net/bugs/66129416:30
jjohansensmb: was looking into this, and I don't believe their is any resolution yet16:31
jjohansenat least I don't see anything in my notes from him16:31
smbwaiting on feedback16:31
jjohansenoh, \o/16:32
jjohansenmorning smb :)16:32
smbstill on phone typing one handed16:32
jjohansenI was just about to say, found it "no usable feedback"16:32
SpamapSsmb: eyes on the road!16:32
ttxtmi16:32
Daviey!16:33
JamesPageDo we want to carry this one to next week?16:33
SpamapSsounds like it16:33
JamesPage[ACTION] Kernel team to follow up on bug 66129416:34
MootBotACTION received:  Kernel team to follow up on bug 66129416:34
ubottuLaunchpad bug 661294 in linux (Ubuntu) "System lock-up when receiving large files (big data amount) from NFS server" [Medium,Confirmed] https://launchpad.net/bugs/66129416:34
JamesPageMoving on....16:34
JamesPage[TOPIC] Natty Development16:34
MootBotNew Topic:  Natty Development16:34
* SpamapS hears crickets16:35
hallyn_i sure do wish firefox plugins work, but other than that natty is treating me well :)16:35
SpamapSI think its about time we set the trend line here: http://people.canonical.com/~platform/workitems/natty/canonical-server.html16:35
SpamapSUnless anybody has some giant new stuff they expect to land in their BP's soon?16:36
jjohansenhallyn_: what video card because X keeps dying on me16:36
SpamapSI'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 precise16:36
hallyn_jjohansen: oh, nvidia is a fail for me right now.  non-accelerated nouveau16:36
ttxSpamapS: who needs a trends line set when there is... inverted burndown charts !16:37
jjohansenah, I'm using an intel igp - can't even make it to the desktop :(16:37
SpamapShallyn_: 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:37
JamesPageDaviey, zul, kirkland, smoser - are you guys happy with the state of your wi's before we do this?16:38
SpamapSttx: 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
ttxSpamapS: We are the only true admirers of real art. Like the bp lp api.16:38
SpamapSJamesPage: its entirely changable too, so no big deal if people add more later.16:38
kirklandJamesPage: meh, happy enough16:38
SpamapSbut it seems like we have a decent number.. 36016:39
smoserwell, my blueprints correctly show my poor progress16:39
zuldoesnt matter either way to me16:39
DavieyJamesPage: I can't see a problem with starting now16:39
SpamapSttx: indeed16:39
JamesPage[ACTION] SpamapS to setup trend line for server team natty work items16:39
MootBotACTION received:  SpamapS to setup trend line for server team natty work items16:39
JamesPagedone16:39
SpamapSBP's are getting an API btw.16:39
SpamapSif any of you missed that16:39
hallyn_i did.  yay16:39
robbiewfwiw, I'd rather have coarse WIs than none at all16:40
ttxSpamapS: Christmas is early, maybe Dec 8.16:40
Davieyttx: My calendar says otherwise!16:40
ttxDaviey: I use a metric calendar.16:40
robbiewttx: could you guys get us sortable/customizable bug columns while you're at it16:40
robbiew:)16:40
JamesPageOK so if we are done with Natty development lets move onto....16:40
JamesPage[TOPIC] Weekly Updates & Questions for the QA Team (hggdh)16:41
MootBotNew Topic:  Weekly Updates & Questions for the QA Team (hggdh)16:41
hggdhk16:41
ttxrobbiew: 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
hggdhI have a blocker -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/67624516:41
Daviey:(16:41
Davieysmb / jjohansen ^^ ?16:41
Daviey(That is blocking our test rig)16:41
hggdhTim is working on it, but we need it for alpha1 testing16:42
hallyn_bug 67624516:42
ubottuLaunchpad bug 676245 in linux (Ubuntu Natty) "Broadcom NetXtreme II BCM5709 -- no network found on ISO install" [High,In progress] https://launchpad.net/bugs/67624516:42
jjohansenhggdh: oh, not nice16:42
jjohansenI know its being looked at16:42
smbAnd the first time we probably hear of it?16:42
jjohansenactually tim was talking about it this morning16:42
smbI think JFo was mentioning that a bit ago on kernel16:42
jjohansenyeah16:42
smbCannot say much there. Just finished a phone call16:43
JFoyep :)16:43
jjohansenI don't think there is much to say beyond tim assigned16:44
hggdhyes, I am just raising up the issue -- we have not been able to test either Euca or openstack16:45
hggdhon Natty16:45
jjohansen:(16:45
hggdhapart from that -- thanks to JamesPage, Hudson is up & running on AWS16:45
hggdhso if you want to add slave machines to it... Welcome! and ping James or me to add you as an user16:46
JamesPagehggdh - we also have a first set of ISO install test results - not to bad16:46
hggdhindeed -- only 4 failures, and I will be looking at them in a few16:46
JamesPageping me afterwards - I took a look at some of them today.16:47
JamesPagehggdh: anything else from the QA team?16:47
zulwhere is the url for the hudson server anyways?16:47
hggdhI also added the ISO server results to the QA dashboard (WIP):16:47
JamesPageYou can access it here : http://204.236.234.12:8080/16:47
hggdhhttp://reports.qa.ubuntu.com/reports/qadashboard/qadashboard.html16:48
MootBotLINK received:  http://reports.qa.ubuntu.com/reports/qadashboard/qadashboard.html16:48
hggdhthe page is not yet updated, BTW16:48
* Daviey actions JamesPage to arrange a URL for it. :)16:48
Davieysubdomain16:48
JamesPageDaviey: agreed16:48
hggdhfor the record, this Hudson server is *temporarily* on AWS, we intend to move it later on16:48
JamesPage[ACTION] JamesPage to arrange URL for Hudson CI Server16:48
MootBotACTION received:  JamesPage to arrange URL for Hudson CI Server16:48
hggdhand that's it, right now, from QA16:49
JamesPageExcellent16:49
JamesPage[TOPIC] Weekly Updates & Questions for the Kernel Team (smb)16:49
MootBotNew Topic:  Weekly Updates & Questions for the Kernel Team (smb)16:49
DavieyI think they've already done a dandy job of telling us quite a bit16:50
jjohansenhrmm, I don't have any updates beyond what has already been covered16:50
smbjjohansen, Did we ask about iscsitarget?16:50
jjohansenAh, well I mentioned it in the wrong place but yeah16:51
jjohansenhrmm, though I made it more a statement than a request16:51
JamesPageAnything else from the QA team16:52
JamesPage/QA/Kernel/16:53
smbjjohansen, 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
MootBotNew Topic:  Weekly Updates & Questions for the Documentation Team (sommer)16:53
Davieyno sommer :(16:53
JamesPagesommer around today?16:53
jjohansensmb: well more we are removing it because there is a newer dkms, and no one ran screaming :)16:53
JamesPageanyone spoken to sommer since UDS?16:54
Davieyjjohansen: We'll scream if it breaks :P16:54
jjohansenDaviey: I know you will16:54
smbSounded like everybody was using the dkms version anyway16:54
smbSo there would be no change16:54
Davieygroovy16:54
zuliscsitarget is already using dkms isnt it?16:55
SpamapSJamesPage: 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 Ubuntu16:55
smbzul, Yes as far as we know16:55
smbI think its just the same as once with drbd16:55
JamesPage[TOPIC] Weekly Updates & Questions for the Ubuntu Community Team (kim0)16:56
MootBotNew Topic:  Weekly Updates & Questions for the Ubuntu Community Team (kim0)16:56
kim0hey everyone o/16:56
JamesPageo/16:56
kim0I 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
kim0Other than that, I'm interested in identifying "things the community can help with" as it related to cloud for now16:56
kim0I'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:56
kim0So 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
Davieykim0: last question, probably no at the moment16:57
kim0any thoughts on low hanging fruit .. are most welcome16:57
Davieykim0: How are the cloud community meetings going?16:57
kim0Daviey: the QA ones ?16:57
Davieykim0: the meeting you were driving :)16:58
kim0The first one was good16:58
kim0not too busy though16:58
kim0but we did make use of the full hour16:58
Davieygreat!16:58
kim0it's weekly16:58
kim0so another one is tomorrow16:58
kim0I'll try to put some training16:58
Davieykim0: Plug it here :)16:58
kim0stuff in there16:58
kim0Is it better to use #ubuntu-cloud or here16:58
kim0anyway .. that should be all for me16:59
SpamapSthose meetings are at 7am pacific time btw16:59
SpamapSI'm not saying it because I can't make it..16:59
SpamapSbut because the mecca of all web 2.0 / cloud technology.. san francisco .. can't make it16:59
* kim0 nods 16:59
kim0prolly needs a time change16:59
JamesPageAny other questions for kim017:00
JamesPage?17:00
Davieynone here17:00
JamesPage[TOPIC] Open Discussion17:00
MootBotNew Topic:  Open Discussion17:00
JamesPageAny items for general discussion?17:01
Davieynone here17:01
SpamapSnay say they17:01
DavieyCan we go home now? :)17:01
JamesPageAlmost[TOPIC] Announce next meeting date and time17:01
kim0haha :)17:01
JamesPage[TOPIC] Announce next meeting date and time17:01
MootBotNew Topic:  Announce next meeting date and time17:01
JamesPage:-)17:01
* bjf is drumming his fingers17:01
JamesPageTuesday 2010-12-07 at 1600 UTC - #ubuntu-meeting17:01
JamesPage#endmeeting17:02
MootBotMeeting finished at 11:02.17:02
SpamapSJamesPage: awesome, thanks!!17:02
bjf#17:02
bjf# lets "get 'er done"!17:02
bjf#17:02
JFoo/17:02
bjf#startmeeting17:02
MootBotMeeting started at 11:02. The chair is bjf.17:02
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]17:02
smb\o17:02
bjf[LINK] https://wiki.ubuntu.com/KernelTeam/Meeting17:02
bjf[LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick17:02
bjf#17:02
bjf# NOTE: '..' indicates that you are finished with your input.17:02
bjf#17:02
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting17:02
ckingo/17:02
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick17:02
jjohansen\o17:02
apwo/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
MootBotNew 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:02
bjf[TOPIC] Release Metrics (JFo)17:03
MootBotNew Topic:  Release Metrics (JFo)17:03
JFoRelease Meeting Bugs (6 bugs, 14 Blueprints)17:03
JFo==== Alpha 1 Milestoned Bugs (14 across all packages (up 1)) ====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==== Release Targeted Bugs (103 across all packages (up 8)) ====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==== Milestoned Features ====17:03
JFo * 6 blueprints (Including HWE Blueprints)17:03
JFo==== Bugs with Patches Attached:142 (up 2) ====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-handling17:03
MootBotNew Topic:  Blueprints: Natty Bug Handling (JFo)17:03
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-bug-handling17:03
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.html17: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 currently17:04
JFo  stand. I have also begun doing some draft documentation on how to address these bugs in the proper way. I will17: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. I17:04
JFo  have several tasks identified for this week concerning documenting their process as well as working with17:04
JFo  Deryck H to address the limitation on how many can be processed at one shot.17:04
JFo..17:04
bjf[TOPIC] Blueprints: Kernel Configuration Review (apw)17:05
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review17:05
MootBotNew Topic:  Blueprints: Kernel Configuration Review (apw)17:05
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-config-review17:05
apwAll 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 ongoin17:05
apwg with a report due by natty-alpha-1.17:05
apw..17:05
ubottuLaunchpad bug 669496 in linux (Ubuntu) "natty fails ec2 boot on i386 or t1.micro" [Critical,Confirmed] https://launchpad.net/bugs/66949617:05
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-enhancements17:06
MootBotNew Topic:  Blueprints: Enhancements to the firmware test suite (cking)17:06
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements17:06
ckingChanges to fwts (natty development branch):17:06
cking * ACPI method testing: add some more advice feedback, check for infinite17:06
cking   loop exeception errors.17:06
cking * bios mtrr tests: skip MtrrFixDramModEn test for non-AMD CPUs17:06
cking * acpitables: some MADT / APIC sanity checks, dump out P_LVL3_LAT correctly17:06
cking..17:07
ckinghrm, missed some lines:17:08
cking * bios mtrr tests: skip MtrrFixDramModEn test for non-AMD CPUs17:08
cking * acpitables: some MADT / APIC sanity checks, dump out P_LVL3_LAT correctly17:08
cking * get ACPI version number from /sys/module/acpi/parameters/acpica_version17:08
cking * various build warning fixes17: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-maintenance17:08
MootBotNew Topic:  Blueprints: Handling of Deviations from Standard Kernels (smb)17:08
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-frankenkernel-maintenance17:08
smbI 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-review17:09
MootBotNew Topic:  Blueprints: Review of the Stable Maintenance Process (sconklin / bjf)17:09
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review17:09
sconklinThe first pass through the process went well, although we didn't hold strictly17:09
sconklinto a two-week cadence, as we started with kernels ready for verification.17:09
sconklinWe had great help from certification on this, and they will have a representative17:09
sconklinjoining us in this meeting starting next week.17:09
sconklinWe learned a lot and are refining the process, documented here:17:09
sconklinhttps://wiki.ubuntu.com/Kernel/StableReleaseCadence17:09
sconklinIn preparation for the beginning of the next stable kernel release,17:09
sconklinwe ask that commits to all -next branches be held until the17:09
sconklinstable kernel team has completed merging those changes with17:09
sconklinthe master branches.17:09
sconklinWe will announce on ubuntu-kernel-team mailing list when the -next17:09
sconklinbranches are open again.17:09
sconklin..17:09
apwsconklin,17:10
apwcould you not move the branch over to a new name17:10
apwsort of take a snapshot of it to work with17:10
apw..17:10
sconklinapw: 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, tho17:11
tgardneryeah, what apw said. what good is a -next branch if we can't scribble in it?17:11
sconklinBut yeah, it's a trivial way to handle it17:11
sconklinWe still have a short window during which we reset the branch17:11
apwthe process is bound to evolve17:12
sconklinlet's take this offline17:12
sconklin..17:12
sconklinfor now the -next branches remain closed, at least for a few hours17: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-review17:12
MootBotNew Topic:  Blueprints: Ubuntu Kernel Delta Review (apw)17:12
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-ubuntu-delta-review17:12
apwA 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:12
bjf[TOPIC] Blueprints: Kernel Version and Flavours (apw)17:13
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours17:13
MootBotNew Topic:  Blueprints: Kernel Version and Flavours (apw)17:13
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours17:13
apwPreliminary 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:13
bjf[TOPIC] Status: Natty (apw)17:14
MootBotNew Topic:  Status: Natty (apw)17:14
apwThe 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
MootBotNew 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:14
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
sconklinIn the last week, a security update was prepared and released.17:15
sconklin..17:15
bjf[TOPIC] Incoming Bugs: Regressions (JFo)17:15
MootBotNew Topic:  Incoming Bugs: Regressions (JFo)17:15
JFoIncoming Bugs17: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
JFoCurrent regression stats (broken down by release):17:16
JFo==== regression-potential ====17:16
JFoAs this tag is deprecated, this listing is only to ensure that I keep it on my radar until17:16
JFochanges to the apport hooks and my processing of the currently tagged bugs is completed.17:16
JFo  * 1 natty bugs17:16
JFo  * 394 maverick bugs17:16
JFo  * 178 lucid bugs17:16
JFo==== regression-update ====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==== regression-release ====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==== regression-proposed ====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:16
bjf[TOPIC] Triage Status (JFo)17:17
MootBotNew Topic:  Triage Status (JFo)17:17
JFoThe next bug day will be next Tuesday covering regression-update bugs. there are 118 bugs that need to17:17
JFobe looked at, the majority of which will need to be tested against the latest released version and the current version in17:17
JFodevelopment. I'll send out an e-mail today concerning the day. I'll also post a blog post on our voices page.17:17
JFowhoops17:17
JFowrong bit17:17
JFoThe first iteration of the Bug List is running hourly. It is available:17:17
JFohttp://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html17:17
JFoAs always your feedback on it is much appreciated.17:17
JFoBug Expiration seems to be working. I have seen several bugs Expired by the system recently. I am trying to work out how17:17
JFoto see what is being expired (number wise) versus what we would have expired with our arsenal script. This is mainly to see17:17
MootBotLINK received:  http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team.html17:17
JFoif the process is working as we expect so that I can provide that feedback to the LP team.17:17
JFo..17:17
bjf[TOPIC] Incoming Bugs: Bug day report (JFo)17:18
MootBotNew Topic:  Incoming Bugs: Bug day report (JFo)17:18
JFosee above :)17:18
bjfalready covered ^^17:18
JFo..17:18
bjf[TOPIC] Open Discussion or Questions: Raise your hand to be recognized (o/)17:18
MootBotNew Topic:  Open Discussion or Questions: Raise your hand to be recognized (o/)17:18
bjfthanks everyone17:19
bjf#endmeeting17:19
MootBotMeeting finished at 11:19.17:19
JFothanks bjf :)17:19
apwthanks17:19
smbthanks bjf17:19
ckingthanks17:19
kamalthanks bjf17:19
sconklinthanks17:19
=== apachelogger is now known as releaselogger
=== releaselogger is now known as apachelogger
=== bilalakhtar_ is now known as bilalakhtar
=== diwic_afk is now known as diwic
YoBoYtoc toc19:52
YoBoYdébut de la réunion dans 8 minutes19:52
YoBoYoups sorry wrong channel ^^"19:53

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!