=== Ursinha-dinner is now known as Ursinh
=== Ursinh is now known as Ursinha
=== noy_ is now known as noy
=== apachelogger is now known as fluffymaster
=== yofel_ is now known as yofel
dholbachmako, Technoviking, popey, pleia2: around?11:59
dholbachJeffWaugh     May I add Ubuntu's Bleeding Edge to PlanetUbuntu?     11 UTC12:01
dholbachis the only agenda item - I'm happy to follow up on that via email12:02
dholbachhi popey - is there anything else we should talk about?12:02
popeynot that I can think of12:04
popeykubuntu council?12:05
dholbachah yes, I need to follow up on that thread too12:05
dholbachmako, Technoviking, popey, pleia2: ^ feel yourself poked about this :)12:05
dholbachalso I'll talk to mdke about the wiki licensing again12:05
dholbachbut that's all I can think is on our agenda12:06
dholbachalright, I'll go and send a few mail, update the team report, etc.12:06
dholbachAdjourned. :)12:06
jussiwow, that was quick..12:07
popeydont blink!12:07
popeygreat, I can go to lunch now :)12:08
dholbachpopey: bon appetit12:08
=== Ursinha-afk is now known as Ursinha
=== fluffymaster is now known as apachelogger
MootBotMeeting started at 08:00. The chair is NCommander.14:00
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]14:00
davidmG'day NCommander14:00
NCommander[link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/2010061514:00
MootBotLINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/2010061514:00
NCommanderogra: GrueMaster dyfet ping14:00
NCommanderdavidm: morning14:00
* ogra refuses to take part in a meeting that wasnt announced :P14:00
* GrueMaster mumbles14:00
ogra(you forgot the mail again) :)14:00
* NCommander coughs 14:01
NCommander[topic] Action Items from June 8th, 201014:01
MootBotNew Topic:  Action Items from June 8th, 201014:01
NCommander[topic] NCommander to discuss build timeout with lamont14:01
MootBotNew Topic:  NCommander to discuss build timeout with lamont14:01
NCommanderI discussed it with him, but before we came to a conclusion, the troublesome package (qt4-x11) magically started building again ...14:02
NCommanderso its fixed, though we're not sure why14:02
ograwell, we still need a proper solution for that14:02
ograits not only one package that times out14:02
NCommanderogra: lamont has made it so its easier to update the build timeouts then before, so it can be changed with less pain14:02
ograhmm, k14:03
NCommander[topic] NCommander to poke Keybuk on libnih14:03
MootBotNew Topic:  NCommander to poke Keybuk on libnih14:03
NCommanderlibnih is no longer FTBFS so I'm dropping this item (I didn't get a chance to talk with him or do any FTBFS work all week)14:03
NCommander[topic] Standing Items14:03
MootBotNew Topic:  Standing Items14:03
NCommanderogra: ?14:03
ogralibnih cant build because upstart ftbfs14:04
ograbe sure it will return14:04
NCommanderoh, d'oh. why isn't it on the depwait list then :-/14:04
NCommanderc/o on that item then14:04
NCommander[link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html14:04
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html14:04
NCommanderWe're making progress14:05
ograhttp://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-2.html would be more intresting though14:05
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-2.html would be more intresting though14:05
ogragiven thats our next milestone14:05
ograif we get 4 todos done in that we'll look good for A214:06
ogra5 would be even better :)14:06
NCommanderI refactored and cleane dup the preinstalled d-cd branch last night, so its good for initial merging14:07
ogragive me something to review later today14:07
GrueMasterHow close are we to having daily images?14:07
ogradebian-cd merge, cdimage merge of the publisher scripts14:08
NCommanderGrueMaster: jasper needs to go in archive, we need an MIR, and I need to finish compressed image support14:08
ograand some jasper fixes14:08
ograNCommander, jasper is in the archive since 2 weeks14:08
NCommanderogra: d'oh14:08
* NCommander dons dunce cap14:08
ograbut i cant test it without a working kernel14:08
ogra(which brings us to next topic i guess)14:08
NCommanderI thought we had a working OMAP 3 kernel14:08
GrueMasterNot that I have seen.14:09
NCommander[topic] Kernel Status (cooloney, mpoirier)14:09
MootBotNew Topic:  Kernel Status (cooloney, mpoirier)14:09
ograthe .34 omap3 kernels did work14:09
ograwith the switch to .35 they broke14:09
mpoirieri have yet to test.14:09
mpoiriershould get to it today.14:09
ograGrueMaster, where is the bug you wanted to file yesterday ?14:09
mpoirierin any case,14:09
mpoirierabout SD card ?14:10
ograbug 59438214:10
ubottuLaunchpad bug 594382 in linux-ti-omap (Ubuntu) "Wake up daisy chain activation failed on omap3" [Undecided,New] https://launchpad.net/bugs/59438214:10
mpoirierhaven't looked at it.14:10
mpoirierstill on SD card.14:10
GrueMasterOh, on the sd card.   I'll have to look14:10
GrueMasterI don't have it up atm.14:10
mpoirierfine, I'm looking at code at this time and can reproduce on my rig.14:11
GrueMasterbug 59268814:11
ubottuLaunchpad bug 592688 in linux-ti-omap (Ubuntu Maverick) "Timing issues with certain SD cards on beagleboard" [Undecided,New] https://launchpad.net/bugs/59268814:11
mpoirieryes, that is the one.14:12
GrueMasterShould I assign those to you?14:12
* ogra comments on the bug and adds some pointers14:12
ogra(the daisy chain one)14:12
davidmmpoirier, you need an OMAP3 board correct?14:12
mpoirierI suppose you could.14:12
mpoirierWell, I could use a bb C4.14:13
mpoirierhave C2 atm.14:13
davidmI'll send a C4 out today14:14
mpoiriervery well thank you.14:14
ograDavidLevin, do we still have spare XMs ?14:14
ogradavidm, ^^^14:14
ograsince i see massive issues there too with the curent omap3 kernel14:14
davidmogra, I have 1 unit now14:14
ograi think lag has one14:14
davidmI can ship that if you need it.14:15
ograwell, lag, amitk and me each have one unit, depends if mpoirier will work on XM issues too14:15
davidmNCommander, give me an action to ship mpoirier a C4 this week please14:15
ograthen it would make sense to ship one to him14:15
NCommander[action] davidm to ship mpoirier a beagle C414:15
MootBotACTION received:  davidm to ship mpoirier a beagle C414:15
davidmNCommander, also add ship mpoirier a XM too14:15
NCommander[action] davidm to ship mpoirier a XM board14:16
MootBotACTION received:  davidm to ship mpoirier a XM board14:16
davidmI think I'll cry, every time I get hardware I have to ship it out.....14:16
ogralag, any news about omap4 ?14:17
* NCommander gives davidm a Babbage board14:17
ograwell, we're waiting for a binary package in teh arm team :)14:17
lagI have a working build14:18
ogrado you know whats the progress there is ?14:18
lagBut I didn't build it14:18
lagI'm afraid cooloney is your man14:18
ograyeah, i'm more intrested about something in the archive :)14:18
lagNothing as yet14:18
ograNCommander, move ?14:19
NCommander[topic] QA Status (GrueMaster)14:19
MootBotNew Topic:  QA Status (GrueMaster)14:19
GrueMasterI have been doing a lot of testing and retesting of the image ogra handrolled last week on various sd cards.14:19
ograGrueMaster, could we have a list of milestoned bugs on the meeting agenda ?14:19
ograthat would help a lot with the release meetign preparation and with keeping an easier overview14:20
GrueMasterI can add them later today.14:20
ograonly the critical and high ones that are milestoned14:20
* GrueMaster needs coffee still.14:20
ograshould only be a few each week14:20
* NCommander needs that magicial substance as well14:20
ograNCommander, move ?14:21
NCommander[topic] ARM Porting/FTBFS status (NCommander, dyfet)14:22
MootBotNew Topic:  ARM Porting/FTBFS status (NCommander, dyfet)14:22
* NCommander has nothing to report since he hasn't had time to work on this14:22
dyfetWell, there are some items pending from upstream14:22
dyfet(glib2.0 and gobject introspection)14:22
dyfetI did work on others though as well, and did btrfs-tools14:22
ogradid you tak to seb128 about glib ?14:23
dyfetThats why I did not submit my patch for it14:23
ograanything NCommander or i need to sponsor ?14:23
dyfetI sponsored with rainct :)14:24
dyfetI may have openmpi resolved later today, but I know we need to get kde unstuck14:24
ogracan you make sure your name shows up in the uploads ?14:24
ograelse sponsored uploads wont help you with MOTU14:25
dyfettrue :)14:25
dyfetI had to pass on glib2 since there was an upstream fix being merged...14:25
ograwhat about compiz ?14:26
dyfetI can look at that later tonight or tomorrow14:26
ograand xscreensave seems to have failed too14:26
ograthe rest looks like glib or qt fallout14:27
NCommander[topic] ARM Image Status (ogra, NCommander)14:28
MootBotNew Topic:  ARM Image Status (ogra, NCommander)14:28
ograpretty much covered above already ...14:28
NCommander[topic] AOB14:28
MootBotNew Topic:  AOB14:28
ograwe need functioning kernels14:28
* ogra has an AOB topic :)14:29
ogradavidm, what do we do with the mailing list now that we're being renamed14:29
ograand also with #ubuntu-mobile14:29
NCommanderWell, with #ubuntu-mobile, I thinkw e can let it die, we use #ubuntu-arm mostly now14:30
ograshuld #ubuntu-mobile become a redirect to #ubuntu-arm or do we leave it idling14:30
ograNCommander, define "let it die" :)14:30
NCommanderlet it idle14:30
ograjust leaving it wont magically make it go away14:30
davidmogra, I need to talk with IS about the mailing list14:31
ograits a registered ubuntu channel14:31
davidmogra, I'd leave #ubuntu-mobile idle I think14:31
ograhmm, k14:31
davidm there is value to it, just not for us right now14:31
ograindeed, but someone needs to be the owner (and make sure to be able to OP when spamboats or trolls show up)14:32
davidmhmm, I did not realize it was a registered channel, is #ubuntu-arm registered?14:32
ograi think it is14:32
ograhas a chanserv14:32
davidmWe should likely make sure14:32
ograi think persia cared for -arm back when we got it new14:35
ograNCommander, action for me to talk to persia about IRC channels14:35
NCommander[action] ogra to talk to persi about IRC channels14:35
MootBotACTION received:  ogra to talk to persi about IRC channels14:35
NCommanderCan I close out the meeting?14:35
MootBotMeeting finished at 08:35.14:35
davidmNCommander, you might take a tad more time to let folks respond to closing the meeting14:36
NCommanderdavidm: did you want to say something? (I can open it again)14:36
davidmI used the going 1 - 3 before closing to allow any last minute things14:37
davidmNCommander, no not worth opening again14:37
NCommandersorry about it14:37
davidmmakes a new log14:37
davidmNo worries14:37
sabdflhello all15:01
mdzcjwatson: ping15:01
cjwatsonhi, was just finishing up on the phone with lool15:02
cjwatsonand that's everyone15:02
cjwatsonKeybuk: relaxing then?15:02
MootBotMeeting started at 09:02. The chair is cjwatson.15:02
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]15:02
cjwatson[TOPIC] Action review15:02
MootBotNew Topic:  Action review15:02
cjwatsonI don't see anything in the minutes from the last meeting that requires review15:02
cjwatsonoh, wait15:02
pittiFTR, I'm in a parallel mumble OEM meeting, so I'm lagging a bit15:02
cjwatson The board resolved that the issue of ubuntu-drivers many roles should be a medium-priority bug, and should be fed back to the Launchpad team as part of the usual process15:03
cjwatsonmdz: did you raise that as resolved?15:03
mdzcjwatson: I've passed it on to marjo for the next stakeholder meeting15:03
cjwatsonok, thanks15:03
cjwatson[TOPIC] Review StableReleaseUpdates policy of contacting the Technical Board regarding regressions (mdz)15:04
MootBotNew Topic:  Review StableReleaseUpdates policy of contacting the Technical Board regarding regressions (mdz)15:04
cjwatsonmdz: go ahead15:04
mdzso, we've had a couple of regressions discovered in -proposed recently15:04
mdzand the wiki page tells people to email the tech board15:04
mdzthis doesn't seem like the most helpful point of contact15:05
mdzso I would like to suggest that we direct these reports elsewhere15:05
keesseems like maybe "If you can't reach anyone else who will take responsibility, then email TB..."15:05
pittiright, I usually mark them as regression-proposed/verification-failed to prevent it being copied to -updates15:05
mdzfor example to the QA team, or the SRU team, or someone like that15:05
pittiregressions in -updates are a different story, of course, and we should rather tell more people than fewer15:05
cjwatsonthere's also a rather out-of-date list of individuals in there somewhere15:05
cjwatsonso, wait15:06
cjwatsonI think this is actually bad wording on the page15:06
mdzpitti: yes, I think the page actually only says to email the TB regarding regressions in -updates15:06
cjwatsonmdz: you're looking at the bit under "Procedure", right?15:06
mdzbut people get confused15:06
cjwatsonI'll take an action to reword that so that it explicitly applies to -updates15:07
mdzand I don't think the TB is ideal in that case either15:07
cjwatson[ACTION] cjwatson to reword StableReleaseUpdates to indicate that panic button only applies to -updates15:07
MootBotACTION received:  cjwatson to reword StableReleaseUpdates to indicate that panic button only applies to -updates15:07
cjwatson(pending other discussion - that much is obviously sane, though)15:07
mdzdoes anyone else feel that the panic button could be improved as well?15:08
cjwatsonI share some of that feeling, just thinking15:08
cjwatsonthe point of the panic button is to quickly escalate to people who can be effective15:08
cjwatsonin doing things like reverting the update if appropriate, getting IS to block it if appropriate, etc.15:08
mdzI take pitti's point that we want to make sure the message gets through, but I'd rather see a clear escalation path than a scattershot approach15:09
cjwatsonI think it should be a set of people who have upload privileges (i.e. not in general the QA team - no disrespect intended), in order that if it's appropriate they can revert immediately with minimal fuss15:09
mdzif we want is quick and accurate action, what we want to see is one person acknowledging and owning the problem and escalating it methodically15:09
mdzrather than potentially several people acting at once15:10
cjwatsonwe certainly want to end up with a single owner15:10
mdzIRC is pretty good for this15:10
cjwatsonbut it's valuable not to depend on a single person15:10
mdzbecause everyone else can see if someone has already responded15:10
mdzemailing the TB...not so much15:10
cjwatsonwhich set of people is appropriate?  I would say either ~ubuntu-archive or ~ubuntu-sru15:10
mdzI think ~ubuntu-sru15:11
cjwatsonprobably the latter except that it's kind of small.  but maybe that's ok15:11
cjwatsonwe can delegate15:11
cjwatsondo you think it's appropriate for IRC to be the only method?15:11
pitti~ubuntu-archive would be appropriate, since all of them can use copy-package, lp-remove-package, etc.15:12
pitti~ubuntu-sru has a subset of archive admins15:12
pittiand telling IS to block updates is easier for Canonical folks with the emergency phone numbers15:12
pitticjwatson: IRC seems fine to me; a lot of folks (slangasek, you, mdz, me) use proxies and are online 24/715:14
cjwatsonso should we have an explicit list of people, rather than a complicated set union/intersection?15:14
cjwatsonand explain the rationale for that list, so that we can keep it up to date reasonably easily15:14
mdzideally, a bot could handle this, and look up the team membership in LP15:15
cjwatson(which the current list hasn't been - AIUI Cody isn't the Xubuntu lead any more)15:15
pittiI liked the copy&paste "pitti, cjwatson, slangasek, ...: PANIC" quite a lot15:15
mdzso we keep it all in one place15:15
cjwatson(and Hobbsee hasn't been around much for a while)15:15
pittiit has few technical dependencies (bots, etc.)15:15
cjwatsonmdz: we can probably do that, it's analogous to !ops15:15
pittiand is quick and easy to document and follow15:15
cjwatsonwe could have !sru15:15
pittican this regularly sync team membership from LP without the need to look it up on the fly?15:16
pittiI wouldn't rely on the latter15:16
cjwatsonseems technically possible :-)15:16
mdzthat's all I had to say on the topic15:17
mdzthe main point being dropping the "email technical-board@" step, since I don't think it adds value15:17
mdzthere's nothing on there about creating an incident report either, and perhaps there should be15:17
mdzcjwatson: since you're on the hook for editing the document anyway, could you remove the email-TB step as well if there are no objections?15:19
cjwatsonis somebody interested in taking an action to get the bot changes made?15:19
cjwatsonotherwise it'll devolve to me I guess15:19
cjwatsonthe code appears to be in lp:ubuntu-bots15:19
pittiah, I think I can try spending some time on that15:20
mdzthat bit is less important, maybe we could just ask for help?15:20
mdzit's a bite-sized project someone could step up and do; it doesn't have to be one of us15:20
cjwatsonI'd rather we get it done and close out the topic15:20
mdzfair enough15:20
lool(hi, joining)15:20
cjwatson[ACTION] pitti to (ask for help to) get !sru added to ubuntu-bots15:21
MootBotACTION received:  pitti to (ask for help to) get !sru added to ubuntu-bots15:21
cjwatson[ACTION] cjwatson to remove "mail TB" step from SRU docs15:21
MootBotACTION received:  cjwatson to remove "mail TB" step from SRU docs15:21
mdzmove on?15:22
cjwatsondoko__: are you here?15:22
=== doko__ is now known as doko
Keybukdoko: do you have any sheep?15:22
dokoKeybuk: just a robber for you15:23
cjwatson[TOPIC] Selection of the Linaro GCC for other architectures (doko)15:24
MootBotNew Topic:  Selection of the Linaro GCC for other architectures (doko)15:24
dokocjwatson: how should we proceed? https://wiki.ubuntu.com/TechnicalBoardAgenda has the input about the Linaro GCC and the main question15:24
cjwatsonso doko brought some concerns about this up over the weekend, and was kind enough to write it up for the agenda15:24
cjwatsonthe question for the TB is what we should be doing regarding the default Ubuntu toolchain15:24
cjwatsonactually, I think this is doko's decision as maintainer, but he'd like advice15:24
loolI didn't have the time to prepare anything for the meeting myself, but I wanted to share that I think the concerns are valid one and that it's more important for Linaro that we take a decision one way or the other than deferring too much; we offered support on all architectures, but obivously we have to balance that against time spent on further developments15:25
mdzI don't have context on this; did I miss something on the mailing list?15:25
Keybukdoes the CodeSourcery GCC offer advantages for non-ARM platforms?15:26
cjwatsonmdz: afraid not, this came up over the last couple of days and hasn't hit the list15:26
loolmdz: we had an UDS session on that, but it came up recently that we had not decided on the final list of architectures and that it was starting to get late15:26
loolI think the UDS session called for testing on x86 and arm, and was reserved about usage on other arches15:26
keesif the linaro patchset is only applied to the armel build of gcc, it seems like that minimizes the potential "alienation".15:27
dokothe CS changes include some middle-end changes and changes to backends. the ones we may be interested in are the intel archs and powerpc15:27
cjwatsonkees: doko and lool have both indicated to me that they're reasonably content with that option, and I'm inclined to agree, although there are of course risks associated with having architectures be different from each other15:27
cjwatsonthere are risks with every option though :-)15:28
dokoI do not want to touch archs which are not actively supported in the CS GCC15:28
loolYes; the smallest maintenance burden is when the toolchain is the same on all arches obviously; in any case, we can do some tests on intel even if Linaro patches aren't used on intel in Ubuntu15:28
keescjwatson: right, it just seems like that one contains the risk a bit more.  doing archive rebuilds is very expensive.15:28
sabdflus using the CS patches for all arch's would help accelerate their upstreaming15:29
cjwatsonlool: smallest> well, depends on how you look at it, the ability to forward patches upstream to the FSF and have them not be rejected is a maintenance win too15:29
loolcjwatson: Linaro also forwards patches upstream though15:29
sabdfland if there's an easy way to get a package built on x86 without the patches, we have a good way to triage toolchain/CS issues15:29
dokothe non-technical question I see is, how is Ubuntu seen if it uses a toolchain not directly from upstream15:29
loolcjwatson: it's our mission to upstream this stuff too, so we could in the end help upstreaming15:30
cjwatsonmy concern about using the CS patches for all architectures is that, if push comes to shove, CS's priorities for Linaro are going to be ARM15:30
cjwatsonI realise that they and Linaro have offered support otherwise15:30
cjwatsonbut I can't see how it can be top priority if there's a crunch15:30
sabdfldoko: i can see it providing an easy excuse for someone to dismiss a bug report from us, but those people will likely find other reasons if we don't give them this one15:30
kikocjwatson, possibly -- but they do maintain the x86 side of the toolchain as well, just to be clear15:30
cjwatsonkiko: not exclusively15:30
cjwatsonthey certainly help to do so15:30
looldoko: this was brought up at the UDS session, one thing which we mentionned, albeit not a full answer, is that we should still provide FSF packages in Ubuntu (gcc-snapshot being one)15:30
dokocjwatson: not exactly, having an "interest" and providing support is different15:30
kikocjwatson, no, I mean that they have x86 customers15:30
loolsabdfl: we provide gcc-snapshot though15:31
kikoso they do maintain it as well15:31
cjwatsonFAOD I am not questioning either CS's skills or good faith15:31
loolit does make things harder for e.g. doko because he has to reproduce an issue with a FSF toolchain first, but he might have to do that anyway?15:31
sabdfllool: right, so it's always possible to test if the CS work is the root cause of an issue15:31
dokolool: yes, we'll have a GCC version which is close to the upstream branches15:31
looldoko: Do you currently test with a vanilla toolchain before reporting upstream?15:31
cjwatsonsabdfl: that's time-consuming work in an already time-consuming process, of course15:31
cjwatsonI wonder if we should take a slightly different approach15:32
sabdflwe face this same story on kernel and elsewhere, anywhere we deviate from pristine upstream15:32
sabdflcjwatson: yes, i understand that15:32
loolYes, albeit the difference is substantial15:32
cjwatsonpackage both the FSF gcc and the CS branch as separate packages15:32
cjwatsonthen, if there's a problem with one, a package can build-depend on and compile with the other15:32
sabdflhow expensive are rebuilds?15:32
cjwatsonassuming that ABIs haven't skewed too much15:32
cjwatsonsabdfl: very!15:32
dokolool: yes, depends on the situation. currently testing with both debian and ubuntu and trunk before reporting bugs15:32
cjwatsonat least in Ubuntu15:32
mdzcjwatson: I guess I took that as a given15:32
loolcjwatson: Yes, just like gcc-4.5/gcc-4.4, gcc-linaro-4.4/4.515:33
mdzthat if we are going to use two different toolchains, we would package them separately15:33
cjwatsonmdz: it wasn't doko's original proposition, but I'm interested how he feels about it15:33
dokocjwatson: well, there's still the problem of overlapping packages (runtime libs)15:33
cjwatsonsabdfl: full rebuilds in Ubuntu are significant mirror-losing events15:33
cjwatsondoko: mm, the runtimes concern me less really although I can see why we might want to think about them ...15:33
loolmdz: the options so far was to apply a Linaro patch in the gcc-4.4 build15:33
sabdflcjwatson: sorry, i meant private rebuilds not hammering-the-archive15:33
loolthere were other options, but basically resulting in the same15:33
lool(e.g. have gcc-4.4 on some arches, and gcc-linaro-4.4 on others)15:34
cjwatsonsabdfl: oh, well, they monopolise PPA builders for the best part of a week IIRC15:34
looldoko: So in a way, you already have the pain of testing with a trunk toolchain, that doesn't change; it just makes it more likely that you hit branch specific bugs15:34
sabdflif it's a question of more builders, that's relatively cheap15:34
cjwatsonand for Linaro we're designing for them, although I imagine we still don't want to do that too often15:34
cjwatsonor more often than necessary15:34
sabdfldoko: when you say trunk, you mean tip?15:35
mdzlool: I would prefer that we package both, and let both build on both architectures, to make it easier to isolate bugs15:35
dokosabdfl: yes15:35
cjwatsondoko: how tight is the binding between g++-4.4 and libstdc++6-4.4-dev15:35
cjwatsonmdz: doko's right though, got to pick one or the other to win libgcc115:35
loolmdz: It's possible albeit expensive, for buildd time and for the maintenance of the forked debian/15:35
cjwatsonand libstdc++615:35
dokocjwatson: it should be merged15:35
cjwatsondoko: I'm not sure what that means15:35
loolmdz: but I see the value in your point15:35
mdzcjwatson, doko: are the runtime libraries significantly different?15:35
kikosabdfl, cjwatson: one thing I asked yesterday, and that I'd like to reiterate, is that we at the moment we don't have the results of a test rebuild back, so we're not very well-informed as to the impact of the toolchain change15:36
loolSufficiently that we need to include the CS patchset in gcc-4.515:36
mdzlool: why buildd time? the toolchain doesn't change that much15:36
dokomdz: the only concern is libstdc++6, but we already have this problem with the 4.4/4.5 overlap15:36
mdz(that often, rather)15:36
kikosabdfl, cjwatson: so while we should be careful to consider things now, we could postpone making a decision until we do have a rebuild as evidence15:36
loolmdz: No, but the time to deploy a fix across all toolchains is longer; toolchain build time is very long, on armel notably15:36
sabdflkiko: we could ack CS patches subject to "no disasters in the rebuild review"15:36
kikosabdfl, right15:36
looldoko: The runtime opts are also very important15:36
cjwatsonI'd like us to explore doko's question of the community impact of using the CS patches as well, when we're ready15:36
mdzlool: fair point15:37
dokokiko: yes, we only have test packages since the weekend15:37
kikodoko, great job getting them ready! :)15:37
mdzwe need to look at this as an ongoing concern, not a one-time decision15:37
cjwatsonI don't agree with sabdfl that people who reject bugs on those grounds would reject them anyway; I've certainly been the guy who rejects bugs on the grounds that it's really better for them to be handled somewhere else15:37
cjwatsonand I don't agree that that's an ipso facto unreasonable thing to do15:37
loolkiko: I would be careful not deferring too much, as noted earlier, as toolchain should get early in maverick15:37
kikolool, I know, but a test rebuild is the minimal due diligence, do you not agree?15:38
mdzhaving a current CS toolchain in the archive at all times seems like a win15:38
mdzthat's something of value beyond just building our packages15:38
loolkiko: I tend to think we should have one for x86 but can't afford to wait for an armel one15:38
dokowe could have as well a decision for this cycle only (gcc-4.4) and revisit the question for mav+1 and gcc-4.515:38
loolThis is compensated by the battery of test which Linaro does before releasing (which is CodeSourcery's)15:39
sabdfldoko: +115:39
kikolool, I'm not thinking of an armel rebuild! just x8615:39
cjwatsonso if it's for this cycle only, in Ubuntu, then my inclination is strongly in favour of saying that we have already passed the point where we should have essentially settled on our core toolchain15:39
looldoko: We do want the Linaro patches in 4.5 though, especially the runtime ones; I'm happy to revisit the decision of Linaro patches in the default ubuntu-n compiler though15:39
sabdflcjwatson: there's no version change, which is the primary question15:39
cjwatsonat least for architectures other than armel, which I agree is special in many ways15:39
cjwatsonsabdfl: I think the version is misleading15:40
loolkiko: We can take a decision including the outcome of the rebuild15:40
dokolool: the armel decision is independent from that one; I'd like to wait until I get feedback from CS about the merged packages first15:40
looldoko: (I'm not exactly sure which issue you relate to)15:41
cjwatsonswitching from 4.4 to 4.4+CS requires just as much diligence as switching from 4.4 to 4.5, IMO - the presence of the string "4.4" in the former shouldn't distract too much from the fact that it's still a major change15:41
dokolool: having the CS patchset applied for armel15:41
kikocjwatson, doko: when I spoke to mark mitchell about this, I made it clear we'd expect him to cover fallout from cross-architectural problems in using the toolchain, and I'm ready to hold him accountable15:41
sabdflanother way to look at it is that having the CS folks focused on our toolchain broadens the eyeballs we have on GCC substantially15:41
loolcjwatson: Yes, it's a large change, smaller than 4.4 -> 4.5, but still a large change necessiting a rebuild15:41
sabdflthey are very good, by all accounts15:42
kikoor, said more nicely, that I'd be sure they were plugged in and paying attention to the bugs found and provided fixes in the time we need them15:42
looldoko: Sorry, I got confused in the discussion and don't understand the point  :-(15:42
sabdflit smooths the way for their work to get upstream mainline too15:42
cjwatsonas I said, I raise no question regarding the CS folks' skills or good faith15:42
mdzcan we agree to rule out changing the x86 toolchain such that a rebuild is required in maverick?15:42
sabdflwe're still quite early in the cycle15:42
cjwatsonsabdfl: (does it really?  CS already has folks on the GCC steering committee, I'm not sure how much another customer in fact helps)15:42
loolkiko: MarkM will do that as long as long as it's in the Linaro goals, and it will be time-bound, because we have other Linaro goals to achieve15:43
sabdflnot many customers are as high profile or build as much15:43
dokomdz: I can't think of changes that absolutely would require a rebuild15:43
mdzdoko: lool just said that this would necessitate a rebuild15:43
kikolool, no, he'll do it as part of the agreement to use his toolchain as default for us.15:43
cjwatsonmdz: test rebuild15:43
mdzdoko: the CS patches, that is15:43
loolmdz: it is a good idea to do a test rebuild15:43
loolmdz: not to rebuild the Ubuntu archives15:43
kikolool, well, that's how I've presented it, anyway15:43
loolmdz: that is, I would rather do a test rebuild before uploading such a makor change15:43
cjwatsonkiko: what will happen if there is a time conflict between Linaro/ARM work and Ubuntu/(say)x86 work?15:43
cjwatsonwhich will win?15:43
mdzlool: oh, that's something different then15:44
dokomdz: right, it requires a test rebuild outside the archive, before the changed GCC is a candidate for upload15:44
loolmdz: No rebuild is needed, the ABI is compatible, and upwards15:44
mdzdoko: yes, naturally15:44
loolIt's a different story if we need to roll it out, that might be worth covering15:44
kikocjwatson, we'll make sure CS fixes the critical bugs15:44
looldoko: Do you think we would need to rebuild binaries if we were to rollback *out* of the CS patches on x86?15:44
mdzdoko: but what about testing that those rebuilt packages actually work?15:44
kikocjwatson, I'm saying this because I know that they care about the state of their toolchain across architectures15:44
kikocjwatson, and they will appreciate the additional testing15:44
dokokiko: yes, I may be overcautious, but there may be gap if Linaro/CS runs out of time15:45
kikodoko, we'll make it work15:45
cjwatsonkiko: when I talked to them in person last week, they did say that there had been very little field testing of native builds on any architecture15:45
cjwatsonand that essentially it was just the standard test suite15:45
kikocjwatson, all the more reason for them to pay attention to problems we find15:45
loolit's true, they mostly do cross-compilers and cross-compilation, but I'd be inclined to think it's less likely to break this way around15:45
cjwatsonagreed, but nevertheless it gives me concerns regarding a late deployment of the toolchain on Ubuntu x8615:45
mdzthe more I hear, the more strongly I feel that the toolchains for x86 and ARM should be decoupled15:45
dokomdz: yes, we could do a test CD rebuild from the rebuilt packages15:45
cjwatsonand I have to stress that, this is late15:45
kikocjwatson, look, this is absolutely a bit of a leap of faith; I'd rather we had the results of a test rebuild to be talking facts instead of speculation15:45
cjwatsoncertainly, and I think this will be an easier discussion for maverick+1 anyway15:46
loolI think we could take a decision depending on how good the rebuilds are15:46
cjwatson(not that I'm saying we should defer the whole discussion to then)15:46
cjwatsonmdz: for maverick, my leanings are also in that direction, at the moment15:47
cjwatsonI agree that a test rebuild will be useful information15:47
kikoI can't evaluate the cost it has maintaining two separate toolchain packages in the archive for the architectures; I think it's painful but I'm not sure how much. so that needs to be balanced out with the risk of adopting something else -- and without a test rebuild we can't really say how much risk there is15:47
kikohow long will it take to run a rebuild, doko? is it running already?15:48
mdzkiko: my gut feel is "less painful than the tug-of-war between x86 and ARM"15:48
dokoI think a test rebuild for main should be doable until the next TB meeting (not sure about ARM)15:48
loolkiko: Note that the pain is present in any case because I understand some Ubuntu arches will not use the Linaro patches15:48
looland in any case doko would like to keep the option open of moving out of hte patches15:48
lool(finally Debian and Ubuntu patches are very similar and doko is maintaining the Debian patches, but that's another story)15:48
kikodoko, I really only care about an x86 rebuild15:49
dokokiko: will start this as soon as I get some feedback of some regressions in the GCC testsuite, which were seen after applying the patchset15:49
mdzkiko: why?15:49
kikomdz, because it is the fastest way to obtain more information15:49
kikoand I hate deciding without adequate information  :-)15:50
dokoI worked through all Ubuntu patches today with CS, they are mostly complementary15:50
kikodoko, have they replied to you yet?15:50
kikooh, that s great to hear15:50
dokokiko: had a 5h phone call today15:50
mdzkiko: it would only give us information about x86, which is the least interesting bit. we already have an adequate toolchain for x86 for maverick.15:51
cjwatsondoko: complementary> as in, no serious conflicts?15:51
kikomdz, I don't know what adequate means, but we should have more information to decide on whether to fork the toolchain or not.15:51
mdzkiko: a rebuild will not tell us what this decision will mean for the next four months15:51
dokowe should be able to start a test rebuild later this week.15:51
loolmdz: We're not trying to get many improvements in the maverick toolchain, but using the same toolchain on x86/armel/ppc would have a benefit, especially if we drop ia64/sparc15:51
mdzkiko: as I understand this discussion, forking the toolchain is inevitable. it's just a question of how we manage the fork.15:52
dokocjwatson: yes, and many arm patches we applied for karmic and lucid not in the CS changes15:52
kikomdz, to me that wasn't clearly decided -- and I'd rather we didn't decide until we had more information15:52
mdzkiko: if you were happy with the current toolchain, we wouldn't be here right now :-)15:53
kikobut if we can't wait for a week then I guess your option is definitely the safest15:53
mdzI am not opposed to waiting a week15:53
cjwatsona week will put the toolchain change after alpha-215:53
cjwatson(in practice)15:53
mdzbut I also don't expect the result of a rebuild to have any significant impact on this decision15:53
kikoeven in the edge cases of zero failures or millions of failures? ;-)15:54
mdzsome things will build correctly, some will fail to build, and others will build but may not work15:54
looldoko: 16:44 < lool> doko: Do you think we would need to rebuild binaries if we were  to rollback *out* of the CS patches on x86?15:54
looldoko: I wonder if it's expensive for us to rollback to the FSF toolchain if we chose the Linaro one on x8615:55
mdzkiko: I don't like the idea of pushing CS on x86 even if everything happens to build OK15:55
keesme either15:55
mdzthis is a decision we have to live with; we can't base it only on what happens today15:55
mdz(even if we could test it more thoroughly)15:55
dokolool: currently I don't see why we would need to do so15:55
loolOk, so it seems we would be taking a moderate risk if we need to roolback the toolchain, that's good to know15:56
cjwatsonwe have only a few minutes left, and we seem to have settled into fixed positions15:56
dokoit's a bit more expensive to backout gcc-4.515:56
cjwatsondoko: do you think you have what you need here, or is there anything else you want to specifically discuss?15:56
sabdflx86 CS is not a high risk15:58
dokocjwatson: I think I have the feedback I did want to have. will prepare a summary for tomorrow. and doing the test rebuild for a final decision15:58
sabdflthe risks appear to be with sparc or ia6415:58
sabdflwhich are being deprecated15:58
mdzsabdfl: you sound pretty confident in that15:58
sabdflbased on comments here, yes15:58
dokowhich we *hope* are being deprecated ;)15:58
loolsabdfl: that's correct, albeit CS wants its source to be correct and I've asked them to provide support even on these arches on a best effort basis15:58
lool(I'm commenting on ia64/sparc)15:59
cjwatsonmy feeling is that x86 CS is about as high a risk as switching to 4.5 - and that feels risky at this point in the release cycle too, TBH15:59
dokocjwatson: well, it should not introduce package build failures which need sourceful uploads, as 4.5 would require16:00
mdzand the benefit would be negligible16:00
cjwatsonI'm going to have to cut us off here due to time.  I suggest that further discussion move to #ubuntu-devel or ubuntu-devel@lists16:01
dokomdz: well, the benefit would be better code generation even on ix86. I'll follow up on ubuntu-devel16:01
cjwatsonthere is one article on the mailing list which probably needs attention by somebody, namely https://lists.ubuntu.com/archives/technical-board/2010-June/000281.html16:02
mdzI also noticed in checking the mailing list that it is flooded with spam16:02
cjwatsonbut we probably don't have time to look into it now, if anybody has a moment please follow it up16:02
cjwatson[ACTION] cjwatson to find out about spam-cleaning technical-board@ archives with IS16:02
MootBotACTION received:  cjwatson to find out about spam-cleaning technical-board@ archives with IS16:02
mdzthe bug in that message is bug 58649716:02
ubottuLaunchpad bug 586497 in unattended-upgrades (Ubuntu Lucid) "kpackagekit install security update in automatic mode without authorization" [High,Confirmed] https://launchpad.net/bugs/58649716:02
cjwatsonI haven't been seeing the same spam by mail but I suppose spamassassin could be filtering it here16:02
cjwatson[TOPIC] Check up on community bugs (standing item)16:02
MootBotNew Topic:  Check up on community bugs (standing item)16:02
cjwatsonjust the ubuntu-drivers bug discussed earlier16:03
cjwatson[TOPIC] Select a chair for the next meeting16:03
MootBotNew Topic:  Select a chair for the next meeting16:03
keesI think I'm up next to chair, is that right?16:03
cjwatsonI make it kees16:03
keesdone and done.16:03
MootBotMeeting finished at 10:03.16:03
mdzthanks cjwatson16:03
cjwatsonsorry for the slight overrun, all16:03
pittithanks everyone16:03
sabdflcheers all16:03
=== kiko is now known as kiko-fud
=== fader__ is now known as fader_
mpoiriermpoirier \o17:58
* apw bounces in17:58
* cnd turned into a spider17:58
* smb is there17:58
* apw stamps on cnd17:58
JFoI thought you were doing dips cnd :)17:58
MootBotMeeting started at 11:59. The chair is bjf.17:59
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]17:59
bjf[LINK] https://wiki.ubuntu.com/KernelTeam/Meeting17:59
bjf[LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick17:59
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting17:59
MootBotLINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick17:59
bjf# NOTE: '..' indicates that you are finished with your input.17:59
bjf[TOPIC] Release Metrics: (JFo)18:00
MootBotNew Topic:  Release Metrics: (JFo)18:00
* cking here18:00
JFoBugs (Release Meeting Bugs / RC Milestoned Bugs / Release Targeted Bugs)18:00
JFoRelease Meeting Bugs (1 bugs, 9 Blueprints)18:00
JFo==== Alpha 2 Milestoned Bugs (29 (up 24)) ====18:00
JFo * 10 linux kernel bugs (up 9)18:00
JFo==== Release Targeted Bugs (83 across all packages (up 33)) ====18:00
JFo * 17 linux kernel bugs (up 14)18:00
JFo=== Milestoned Features ====18:00
JFo * 13 blueprints18:00
JFo*** NOTE: This listing includes HWE Blueprints***18:00
JFo==== Bugs with Patches Attached:117 (down 5 from last week) ====18:00
JFo * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on18:00
JFo * Breakdown by status:18:00
JFo   http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/18:00
bjf[TOPIC] Blueprint: kernel-maverick-apparmor (jjohansen)18:01
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor18:01
MootBotNew Topic:  Blueprint: kernel-maverick-apparmor (jjohansen)18:01
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor18:01
jjohansenslow progress - updated compatibility code, need to do testing and send out pull request when done18:01
lagOh, I missed the hellos18:01
bjf[TOPIC] Blueprint: kernel-maverick-firewire-stack (manjo)18:02
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack18:02
MootBotNew Topic:  Blueprint: kernel-maverick-firewire-stack (manjo)18:02
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack18:02
manjonothing to report18:02
bjf[TOPIC] Blueprint: kernel-maverick-misc (apw)18:02
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc18:02
MootBotNew Topic:  Blueprint: kernel-maverick-misc (apw)18:02
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc18:02
apwThe debian commonisation is progressing well, both Karmic and Lucid branch sets have been converted over.  There is some resistance to applying these changes to Karmic currently as they are very hard to review and seen as perhaps outside the SRU process; discussions are ongoing but we may have to abandon doing this for Karmic.  We have also mothballed a no longer used branch in Karmic, the netbook branch.18:02
cnddoes this lift a hold on lucid patches against mvl-dove?18:03
bjfi believe that eric was waiting on this, so it should be a lift18:04
smbI pulled the tree that eric gave cnd18:04
cndsmb, for the LSP 5.2.1?18:04
smbSo the tree should be ok now but the upload is waiting18:05
bjfdid he send out a new one for review after I NAK'd the last one?18:05
smbbjf, I thought it was a revised one18:05
bjfok, don't remember seeing it18:05
cndif not, I can rebase and find any compile failures and send a fix18:05
smbbjf, But I must admit he was confusing me quite a bit with all the pull request18:05
bjf[TOPIC] Blueprint: kernel-maverick-new-kernel-on-lts (tgardner)18:06
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts18:06
MootBotNew Topic:  Blueprint: kernel-maverick-new-kernel-on-lts (tgardner)18:06
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts18:06
tgardnerThe LTS backport kernel and meta packages at http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu are up to18:06
tgardner2.6.35-3.4 (tracking the latest maverick kernel release). All appears well. In fact, its much better then18:06
tgardnerthe previous 2.6.35-rc2 based release which had some memory corrupter bugs.18:06
bjf[TOPIC] Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)18:06
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel18:06
MootBotNew Topic:  Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)18:06
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel18:06
jjohansenpv-on-HVM drivers don't help us out :(18:06
jjohansenKarmic pv-ops kernel on EC2 is more flaky than it was in the Karmic cycle (only successfully booted in 1 of 4 availability zones)18:06
jjohansenLucid pv-ops is boot in 2 of 4 availability zones on last test18:06
jjohansenMaverick wasn't booting at all under, have tried it with the latest config changes made pulled forward from Lucid and haven't tried .3 yet18:06
jjohansenCurrent plan is revert to full Xen topic branch, and get other work items done and return to pv-ops kernel in a few weeks.18:06
bjf[TOPIC] Blueprint: kernel-maverick-tracing-support (cnd)18:07
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-tracing-support18:07
MootBotNew Topic:  Blueprint: kernel-maverick-tracing-support (cnd)18:07
apwjjohansen, wasn't there a third option?18:07
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-tracing-support18:07
jjohansenapw: yeah the third option was full xen18:08
apwok a middle option :)  the drivers only ?18:08
cndPatch sent upstream for perf probe under review. I've packaged trace-cmd and kernelshark, sent three patches upstream for them (2 trace-cmd, 1 kernel). Will work on getting them into Maverick.18:08
jjohansenright the drivers are the pv-ops-HVM18:08
bjf[TOPIC] Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara)18:09
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review18:09
MootBotNew Topic:  Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara)18:09
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review18:09
ogasawaraI pushed 3 of our sauce patches upstream which just removed some18:09
ogasawaraduplicate device id's.  I've also dropped 2 more sauce patches which18:09
ogasawaraadded MODULE_ALIAS for the Dell WMI module and the other which sent18:09
ogasawaraevents on data interface as well as master interface for the hostap18:09
bjf[TOPIC] Blueprint: kernel-maverick-union-mounts (apw)18:09
bjf[LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-union-mounts18:09
MootBotNew Topic:  Blueprint: kernel-maverick-union-mounts (apw)18:09
MootBotLINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-union-mounts18:09
tgardnerogasawara, you got some pushback on one of those removals. what came of that?18:09
apwWaiting on testing from Foundations from updated kernels.  Need to get the tools updated for this and uploaded to the same PPA, hoping to have those tommorrow.18:10
ogasawaratgardner: hrm, I didn't see any reply.18:10
ogasawaratgardner: I'll have to look into it18:10
tgardnerogasawara, the one with duplicate IDs18:10
ogasawaratgardner: I'm not subscribed to the upstream list so I wonder if I wasn't CC'd on the reply?18:11
tgardnerogasawara, likely18:11
apwgoogle is your friend18:11
bjf[TOPIC] Blueprint: kernel-maverick-bug-handling (jfo)18:11
bjf[LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling18:11
MootBotNew Topic:  Blueprint: kernel-maverick-bug-handling (jfo)18:11
MootBotLINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling18:11
JFo* Conversation with the Forums people has begun, they are talking internally to gather some thoughts on our proposal concerning the discussion between us to improve the quality of the information on the forums. They will be gettting back with me late this week or next week and we will go from there.18:12
JFo* I have tested the SHA1 gathering script several times now. It will likely not be as useful as i thought due to the fact that the janitor puts a comment containing the SHA1 of the fix that solves an issue in bugs that potentially have multiple tasks, thus giving us false positives. I am working to define the problem before I see if we can modify the script to react to those comments appropriately.18:12
JFo* I sent out the initial e-mail to get an idea of the interest level for a Kernel Triager Summit. Based on the response, I will begin the further planning items needed to make this a reality.18:12
manjoJFo, are we having community bug days ?18:13
JFothat information is coming up manjo18:13
bjf[TOPIC] Blueprint: kernel-maverick-upstart (apw)18:14
bjf[LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart18:14
MootBotNew Topic:  Blueprint: kernel-maverick-upstart (apw)18:14
MootBotLINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart18:14
apwWaiting on testing from Foundation from updates kernels.  Expecting preliminary feedback on Wednesday.18:14
bjf[TOPIC] Blueprint: kernel-maverick-bios-test-automation (cking)18:14
bjf[LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bios-test-automation18:14
MootBotNew Topic:  Blueprint: kernel-maverick-bios-test-automation (cking)18:14
MootBotLINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bios-test-automation18:14
ckingAdded the following functionality to the firmware test suite:18:15
cking  Battery Test: Exercise CPU to drain quicker18:15
cking  Kernel Version checking18:15
cking  Include Blank Test Template18:15
cking  Re-organise klog scanning, added more intelligence18:15
cking  Logging: Add line numbering, test failure levels, summary of failures, improved automatic text formatting18:15
cking  Add --no-s3 --no-s4 options to ignore suspend/hibernate tests18:15
cking  Check for redundant _OSI(Linux)18:15
cking  HPET sanity check vendor ID18:15
cking  Syntax check SSDT tables18:15
cking  Virtualisation extention checks18:15
cking  Add in MCFG test18:15
cking  General bug fixing and code tidying18:15
bjf[TOPIC] Status: Maverick (ogasawara)18:15
MootBotNew Topic:  Status: Maverick (ogasawara)18:15
ogasawaraWe've rebased to 2.6.35-rc3 which should be available as of18:16
ogasawaralinux-2.6.35-3.4.  Please test.18:16
ogasawaraAlpha 2 is Thurs July 1 (ie ~2weeks from today) so make sure you're on18:16
ogasawaratrack with any work items that need doing as we're currently above the18:16
ogasawaratrend line in our Alpha 2 burn down chart:18:16
ogasawara[LINK] http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-2.html18:16
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-2.html18:16
ogasawaraAlso keep in mind that if you have any patches which you want to land18:16
ogasawarain the Alpha2 kernel, they need to be sent to the kernel-team ml and18:16
ogasawarahave garnered the appropriate Ack's *before* Fri Jun 25.  I'll send an18:16
ogasawaraemail reminder this Friday.18:16
bjf[TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)18:17
MootBotNew Topic:  Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)18:17
smbDapper:      2.6.15-55.84  (security)18:17
smbHardy:       2.6.24-28.70  (security)18:17
smb             2.6.24-28.71  (waiting for approval)18:17
smbJaunty:      2.6.28-19.61  (security)18:17
smbKarmic:      2.6.31-22.60  (security)18:17
smb             2.6.31-22.61  (waiting for approval)18:17
smb - mvl-dove  2.6.31-214.28 (security)18:17
smb             2.6.31-214.29 (waiting for approval)18:17
smb - fsl-imx51 2.6.31-112.28 (security)18:17
smb             2.6.31-112.29 (waiting for approval)18:17
smb - ec2       2.6.31-307.15 (security)18:17
smb             2.6.31-307.16 (waiting for approval)18:17
smbLucid:       2.6.32-22.36  (security)18:17
smb             2.6.32-23.37  (proposed)[4]  8/39 verifications done (+ 8)18:18
smb - LBM       2.6.32-23.37  (proposed)[1]  1/ 3 verifications done (+ 1)18:18
smb - mvl-dove  2.6.32-205.18 (security)18:18
smb             2.6.32-206.19 (waiting for approval)18:18
smb - fsl-imx51 2.6.31-608.14 (security)18:18
smb             2.6.31-608.15 (waiting for approval)18:18
smb - ti-omap   2.6.33-501.7  (security)18:18
smb             2.6.33-502.8  (waiting for approval)18:18
smb - qcm-msm   2.6.31-802.4  (security)18:18
smb             2.6.31-802.5  (waiting for approval)18:18
smb - ec2       2.6.32-306.11 (security)18:18
smb             2.6.32-307.12 (waiting for approval)18:18
smbAs we found out today there is resistance on the current changes in Karmic18:18
smbwhich only affect the build infrastructure. This needs to be resolved18:18
smbbefore the uploads will be accepted into proposed.18:18
JFothat list is getting huge18:18
bjf[TOPIC] Incoming Bugs: Regressions (JFo)18:19
MootBotNew Topic:  Incoming Bugs: Regressions (JFo)18:19
JFoIncoming Bugs18:19
JFo23 Maverick Bugs (up 8)18:19
JFo950 Lucid Bugs (up 4)18:19
JFoCurrent regression stats (broken down by release):18:19
JFo==== regression-potential ====18:19
JFo  * 8 maverick bugs (up 1)18:19
JFo  * 223 lucid bugs (down 11; to be converted to regression-release)18:19
JFo==== regression-update ====18:19
JFo  * 30 lucid bugs (up 5)18:19
JFo  * 6 karmic bugs (down 3)18:19
JFo  * 4 jaunty bugs (down 1)18:19
JFo  * 1 hardy bug (no change)18:19
JFo==== regression-release ====18:19
JFo  * 136 lucid bugs (up 8)18:19
JFo  * 48 karmic bugs (down 2)18:19
JFo  * 19 jaunty bugs (down 1)18:19
JFo  * 2 hardy bugs (down 1)18:19
JFo==== regression-proposed ====18:19
JFo  * 1 lucid bug (no change)18:19
JFo  * 1 karmic bug (no change)18:19
JFoplease note that these numbers may be a bit off due to a bug we introduced in the last update of the expired script.18:19
bjf[TOPIC] Incoming Bugs: Bug day report (JFo)18:20
MootBotNew Topic:  Incoming Bugs: Bug day report (JFo)18:20
JFoI neglected to announce the Bug Day scheduled for today last week due to travel for the SELF conference. That Bug Day will be held next week. The next bug day will be next Tuesday. We will be focusing on working Confirmed bugs and getting them to either Incomplete, by way of testing or information requests, or Triaged based on the completeness of the bug. My goal is to work through all of the Confirmed bugs to get them in the correct state and work 18:20
JFout the best method for them based on conversation with Andy last week. I am happy with the progress of the Team bug day so far. I'd like to hold this again this week. I am open to continuing the two half days on Friday and Monday again if there is no objection.18:20
JFoAre you all finding the half day Kernel team days on friday and monday useful?18:21
JForather still finding them useful18:21
jjohansenwell I like it18:22
JFo..glad to hear it jjohansen18:22
JFoI think it is better than taking up a whole day18:22
apwi've not managed to help with either of them so far, though i think the format is sane ..18:22
* smb unfortunately did not find time for those, yet18:22
JFoI understand18:23
ckingJFo, not yet been able to find time for this time around18:23
JFoI think i'd like for them to be set on the schedule so that everyone knows when they are and we are consistently having them18:23
JFocking, I understand :)18:23
tgardnerJFo, lets keep doing it in order to see of the idea gets traction.18:23
JFotgardner, will do18:23
bjf[TOPIC] Open Discussion or Questions: Anyone have anything?18:24
MootBotNew Topic:  Open Discussion or Questions: Anyone have anything?18:24
ogasawarao/ (I've got 2 items)18:24
bjfogasawara, go18:24
ogasawaraThere are 3 Alpha2 work items assigned to the canonical-kernel-team in18:24
ogasawarathat blueprint.18:24
ogasawarasconklin, could I persuade you to own those 3 work items? It looked like18:24
ogasawarayou and apw attended this UDS session but apw seems to have enough18:24
ogasawaraAlpha2 work items on his plate.18:24
ogasawarawhile you're looking, the other item was https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-uefi-support18:25
ogasawaraThis also has an Alpha2 work item assigned to canonical-kernel-team,18:25
ogasawara"Investigate situation with Intel graphics drivers on EFI".18:25
ogasawaracking or tgardner, did either of you attend this UDS session?  Can I get18:25
ogasawaraone of you to own this work item?18:25
sconklinogasawara: sure, I can take those18:25
ckingogasawara, nope, it clashed with something else I had to attend18:26
ogasawarasconklin: thanks, much appreciated.18:26
tgardnerogasawara, I volunteer cking as he's already involved with EFI18:26
sconklinI'll edit the blueprint now18:26
manjocan we get some feed back on the firewire stack switch? I think its a matter of blacklisting old modules and whitelisting new ones18:26
* cking will pick it up then 18:26
ogasawaracking: thanks18:26
bjfphunge0, go18:26
ubottuLaunchpad bug 585092 in linux (Ubuntu) "tmpfs umount slowdown" [Medium,Triaged]18:26
phunge0Could I get some feedback on prospects for this bug in lucid?  Upstream devs think they have a real fix to the problem (2nd try), it's been posted to lkml but won't be merged until 2.6.35-rc4 at earliest (when Linus gets back from vacation).  I'm wondering if backporting it would be considered feasible.  If not I'm hoping the workaround could be revisited, it has serious performance downsides.18:27
phunge0Please let me know if there's someone specific I should be talking to.18:27
=== Ursinha-afk is now known as Ursinha
tgardnerphunge0, is this so critical that you can't wait 2 weeks for it to show up in due course?18:27
smbI believe last time they had a fix they reverted it due to hangs in xfs18:27
bjfphunge0, it looks like we are waiting to see what upstream wants to do about it18:28
smbBut it was one of the things I wanted to investigate18:28
apwphunge0, do we have a poninter to the outstanding conversation on that18:28
phunge0it's not critical, but my firm was hoping to migrate to lucid with the SRU18:28
MootBotLINK received:  http://lkml.org/lkml/2010/6/10/25918:28
apwto the 'new' fix?  make it easier for us to track when it hits maverick so we can test18:28
apwphunge0, thanks18:28
phunge0and this blocks us18:28
apwphunge0, us ?18:29
phunge0this is the patchset http://lkml.org/lkml/2010/6/10/17518:29
phunge0my firm, sorry18:29
tgardnerphunge0, it remains to be seen if Jens fix is gonna do the trick18:29
apwphunge0, thats like 13 patches!18:29
tgardnerapw, maybe we can get it via stable :)18:30
apwtgardner, fingers crossed :)18:30
phunge0yeah, this is linus indicating that it might be acceptable for 2.6.3518:30
smbWe might but that will certainly take time18:30
apwcirtainly we should help test it in 3518:30
MootBotLINK received:  http://lkml.org/lkml/2010/6/10/28518:30
phunge0but he pushed back18:30
bjfmanjo, you have the floor18:31
manjoblacklist ohci1394 sbp2 eth1394 dv1394 raw1394 video1394 and whitelist firewire-ohci firewire-sbp2 firewire-core firewire-net in /etc/modprobe.d/blacklist-firewire.conf. As far as I can see this is the only real change that needs to happen to make this switch.18:31
manjoI emailed ubuntu-devel and ubuntu-kernel18:31
apw'this switch' ?18:31
manjoand I don't have any response yet18:31
bjfapw, <manjo> can we get some feed back on the firewire stack switch? I think its a matter of blacklisting old modules and whitelisting new ones18:32
manjoie switch from old firewire stack to new stack18:32
apwso i'd recommend you ask on #ubuntu-devel about this as well18:32
tgardnermanjo, did your email include a patch?18:32
apwthere are some old hands there who can probabally help guide us as to the next step18:32
manjotgardner, no, I thought we talked about this a while back and18:33
manjofoundations need to make that change ?18:33
tgardnermanjo, we can do it as well. we have before18:33
manjoI am happy to send a patch18:33
manjotgardner, to ubuntu-kernel ?18:33
apwmanjo, do we have the alternate userspace stack available ?18:33
tgardnerI want some test results too.18:33
apw(i thought there was one if you switched?)18:33
manjoyep we have both moduels built as of now18:33
tgardnermanjo, yep, ubuntu-kernel list18:34
apwmanjo, i meant the userspace integration, does it work with both ?18:34
tgardnerapw, thats what I meant by test results18:34
manjoapw, there was a bug for which the switch was tested18:34
manjobut I can send a patch with test info18:34
tgardnermanjo, just put the results in the bug18:34
apwsounds good then ...18:35
JFoI think we need a gneral CFT on the new stack then18:35
manjotgardner, will do18:35
tgardnerJFo, good idea18:35
* JFo notes this18:35
manjobjf, can you action me18:35
manjoso that I have this info for the next meeting18:35
JFobjf, action me as well for the sending of the CFT18:36
bjf[ACTION] manjo to send a patch with test info18:36
MootBotACTION received:  manjo to send a patch with test info18:36
JFomanjo, I'll send it once you let me know it is built and where the test kernel is.18:36
bjf[ACTION] jfo to put out a CFT on new firewire stack18:36
MootBotACTION received:  jfo to put out a CFT on new firewire stack18:36
JFothanks bjf18:36
bjfkamal, go18:37
kamalRegarding bug 55349818:38
ubottuLaunchpad bug 553498 in linux (Ubuntu Lucid) "Intel Core i3/i5/i7 hang on resume from suspend (SCI_EN)" [High,Fix committed] https://launchpad.net/bugs/55349818:38
kamalWe have this marked as Fix Committed for Lucid, but the fix in Lucid (my original patch) only helps Dell Studio 155x machines, so isn't really sufficient.18:38
kamalI would like to get M. Garrett's better version of the fix ("Unconditionally set SCI_EN", as it exists now in Maverick) pulled into Lucid so we can fix this for all i3/i5/i7 machines.18:38
kamalWhat is the procedure?18:38
apwkamal, propose it as an SRU patch in the normal way18:38
apwsend it to the kernel-team list etc18:38
tgardnerthat one seems like a good stable update patch18:39
kamalok, will do -- can I change the bug state from "Fix Committed" back to "In Progress" or something also?18:39
smbWould there be chance that GregKH accepts it into stable upstream?18:39
tgardnersmb reads my mind18:39
apwcirtainly worth asking ...18:40
bjfkamal, you can also open a new bug just for the purposes of SRU, point back at the other bug18:40
smbkamal, as bjf suggest18:40
kamalbjf, ok I'll open a whole new bug for this -- should I ask GregKH about this directly?18:40
smbSounds strange that the bug only closes dell but is named generically18:40
kamalthe bug was originally titled "Dell Studio ..." but I changed it after realizing that it affected all (?) i3/i5/i7 machines18:41
apwkamal, yeah we should get the title of the dell only bug fixed to be dell only and make the new one generic18:41
smbkamal, I wonder whether I have not written some notes how to do18:41
smbkamal, let me dig and get back to you18:41
kamalapw: ok, that makes sense re: the bug titling.18:42
kamalsmb: I'll wait for your notes.18:42
kamalthanks folks18:42
bjfanyone else have anything?18:42
bjfthanks everyone18:42
MootBotMeeting finished at 12:42.18:42
JFothanks bjf18:42
apwbjf thanks18:42
manjothanks bjf18:42
kamalthanks bjf18:43
smbthanks bjf18:43
ttxSpamapS, mathiaz: time for a Java discoveraibility discussion after the meeting&call ?18:59
zulgday (channeling my inner dingo)18:59
mathiazSpamapS: sure18:59
mathiazttx: ^^18:59
SpamapSttx: definitely18:59
Daviey ^19:00
jiboumansgood aftermorniving19:00
MootBotMeeting started at 13:00. The chair is jiboumans.19:00
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]19:00
jiboumansthanks all for joining, today's scribe will be Daviey19:01
jiboumans[TOPIC] Review ACTION points from last meeting19:01
MootBotNew Topic:  Review ACTION points from last meeting19:01
jiboumansttx to coordinate testing for Alpha 219:01
jiboumansfor those following along at home, the agenda is up at: https://wiki.ubuntu.com/ServerTeam/Meeting19:01
ttxwhen alpha2 is near.19:01
jiboumansvery well.19:02
jiboumanssmoser to train someone on the release team on the cloud image release19:02
smosernot done.19:02
jiboumanssmoser: anything blocking you?19:02
smoseri will contact release team to make sure someone else is able.19:03
jiboumansalright, let's carry over to next week then; if for any reason there's a block, feel free to flag it early so we can help resolve it19:03
jiboumanssmoser to provide a more detailed work item overview for server-maverick-cloud-kernel-upgrades19:03
smoserthat is done.19:03
jiboumanssmoser: ta19:04
jiboumansall to keep their specs uptodate with workitems and update their status monday EOB19:04
jiboumansseems we have nice status updates on our WI tracker, thanks all19:04
jiboumanshttp://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-2.html for those following along19:04
MootBotLINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-2.html for those following along19:04
jiboumansleaving sommer's action point till his section as he'll be a bit late today19:05
jiboumansmoving on:19:05
jiboumans[TOPIC] Maverick development (jib)19:05
MootBotNew Topic:  Maverick development (jib)19:05
jiboumanswe're half way through the development cycle to the Alpha2 milestone right now19:05
jiboumansmost specs should be around 50% completion right now. If you're off that mark, you may want to review work items and see if any can be postponed or dropped, or ask for some support19:06
jiboumanssome are well ahead of that curve so we should have some slack in that area19:06
jiboumansI now give you ttx to go throught he specifics:19:06
jiboumans[TOPIC] Alpha2 subcycle status (ttx)19:06
MootBotNew Topic:  Alpha2 subcycle status (ttx)19:06
mathiazjiboumans: I've added some WI as I've refined some of the work to be done19:06
mathiazjiboumans: so the percentage completion may move around as I've recorded more accurately what needs to be done19:07
jiboumansmathiaz: excellent; the WIs are meant to reflect the work you intend to do. the numbers are just there to give us a sense of of progress19:07
jiboumansmathiaz: in all cases accuracy trumps number juggling :)19:07
ttxmissed the last 5 minutes19:07
jiboumansttx: sorry, you still have to do your bit19:08
jiboumansttx: [TOPIC] Alpha2 subcycle status (ttx)19:08
ttxAbout alpha2 status ?19:08
ttxWe are going reasonably well19:08
ttxthe UEC specs are slightly late but we've been addressing that19:09
* hggdh blushes19:09
ttxjiboumans: want to do a quick oneliner on progress ?19:09
jiboumansttx: i'd like to highlight the ones that we've just reviewed and rescoped somewhat19:10
mathiazttx: should the update section cover that?19:10
jiboumanswhich i believe is UEC testing, qa-workflow and cloud-init right?19:10
=== Ursinha is now known as Ursinha-bbl
mathiazttx: I'll be experimenting with a new format/template for the status section of BP19:10
mathiazttx: you should see the output of this in the coming days19:10
ttxand cloud-utils and uecec2-kernel-updates19:10
jiboumansttx: can you fill us in what happened on those specs?19:11
ttxmathiaz: good19:11
ttxsorry, my IRc client is acting funny19:11
* mathiaz hands a bottle of wine to ttx 19:11
ttxUEC testing was rescoped to concentrate on fixing the current issues to get to a stable situation, and engage in training new people19:11
ttxqa workflow was moved to A3 to give priority to uec-testing19:12
ttxcloud-init was trimmed down to move prio-3 things as targets of opportunity19:12
ttxcloud-utils first work items were reassigned to clint19:12
ttxand uec-ec2-kernel-updates work items were clarified19:13
ttxI think we now have a stable and clear view on what's expected from everyone19:13
ttxif someone thinks he cannot make it, please raise the red flag !19:13
* mathiaz raises a bottle of wine towards ttx 19:14
jiboumansthanks for that summary ttx19:14
jiboumansthis segways nicely to:19:14
jiboumans[TOPIC] Feature Definition Freeze this week (ttx)19:14
MootBotNew Topic:  Feature Definition Freeze this week (ttx)19:14
ttxLooking at http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-2.html gives you a clear commonly shared view on what's expected19:14
ttxRight, this Thursday is FDF*19:14
ttxwe need to freeze the design on all specs that affect main packages19:14
ttxand present those to the release team19:14
ttxWe should be in good shape there, with the A2+A3 planning we've done so far19:15
mathiazttx: do you have a list of WI that are impacted by FF?19:15
mathiazttx: is this what you're looking for?19:15
ttxmathiaz: no19:15
mathiazttx: or is it more at the BP level?19:15
ttxmathiaz: I ean, no, I'm not really needing that19:15
ttxI need to come up with a list of all specs that will land features in main19:16
SpamapSttx: we've had to play with libmemcached a bit and fork it into two source packages, should I add that to the spec to clarify that we only want the new one in main, not the forked lucid package?19:16
jiboumansSpamapS: yes19:16
ttxand the release team will look into them, so applying some polish to the spec docs can't hurt19:16
ttxyes, updating the spec wikidoc with current design is necessary19:16
* SpamapS digs around under the kitchen sink and emerges with a bottle of windex19:17
mathiazttx: are MIR considered new features?19:17
ttxmathiaz: that's an ongoing debate.19:17
ttxI'd say in that context, yes.19:17
ttxThey want to know what will be hitting them19:17
jiboumansi'd err on the side of caution here too and highlight these19:18
mathiazttx: ok - so what do you expect from the team members?19:18
ttxeven if MIRteam != ReleaseTeam it still affects the contents of main.19:18
ttxtake some time[tm] to review the specs and making sure they are current.19:19
mathiazttx: should I review all my specs and flags wether they're impacted by FF?19:19
ttxI'll take it from there.19:19
mathiazttx: ok19:19
ttxIf I have any question, I'll ask them.19:19
jiboumansmathiaz, ttx: looking at the specs and work items, it looks fairly straightforward19:19
ttxjiboumans: ack, should be straightforward.19:20
jiboumansbut to all, please be aware yourself which items affect FDF so you can answer any questions if need be19:20
=== Ursinha-bbl is now known as GoBrazil
jiboumansttx: anything more on FDF?19:21
jiboumans[TOPIC] Weekly Updates & Questions for the QA Team (hggdh)19:21
MootBotNew Topic:  Weekly Updates & Questions for the QA Team (hggdh)19:21
ttxDid anyone mention that Daviey was the scribe yet ?19:21
jiboumansttx: first thing, yes19:21
zulttx: off hand yes19:21
hggdhon my side19:21
Davieyttx: Shh!19:21
ttxI missed tat as well :)19:21
hggdhrigth now testing the metadata issue fix, and preparing to get to Lexington next week19:22
hggdhno real other news right now (except that the fix does not absolutely good right now)19:22
ttx does not absolutely good ?19:22
ttxas in, doesn't work ?19:23
hggdhttx: sort of. I am still getting metadata failures19:23
mathiazhggdh: what's the state of the lucid ubuntuX.2 SRU19:23
mathiazhggdh: ?19:23
mathiazhggdh: has the package been pushed from -proposed to -updates?19:23
hggdhmathiaz: this was tested last week, and marked verification-done. I think today they made it into -updates19:24
mathiazhggdh: indeed - thanks for testing all the bugs19:24
jiboumanshggdh++ indeed19:25
jiboumansany questions for the QA team?19:25
jiboumans[TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)19:25
MootBotNew Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)19:25
jiboumansthanks hggdh19:25
jjohansenwell first off some updates19:26
* sommer arrives19:26
jjohansenthe pv-ops kernel for EC2 hasn't been working out so we are shelving it for at least alpha2 and will update the Xen patches19:26
jiboumanssommer: good timing, you're up after this ;)19:27
jjohansenseems zul wants to volunteer to work on it19:27
jjohansenthe kernel has some known performance regressions, that will probably be in alpha219:27
smoserboo indeed.19:27
jiboumansjjohansen: as in, the alpha2 kernel will have these known regressions?19:28
jjohansensmoser: well part of that is so I have time to do testing of other amazon stuff19:28
jiboumansjjohansen: then i assume targeted for alpha3 are the fixes to those regressions?19:28
jiboumansjjohansen: where can we read about these regressions btw?19:29
jjohansenhopefully, the problem is known upstream19:29
jjohansenand the fixes will be coming from upstream kernels in later a RC19:29
jjohansenthe kernel team has would like to know some more about Bug #58886119:30
ubottuLaunchpad bug 588861 in linux (Ubuntu Maverick) "Instances block in pending state, and don't start" [High,Triaged] https://launchpad.net/bugs/58886119:30
Davieyjjohansen: hey19:30
jjohansenhey Daviey19:30
ttxDaviey: what's the status of your investigations there ?19:30
DavieyTriaging that is somewhat blocked at the moment, as it seems there are other foundation related issues stopping us from even getting as far as that to reprdouce19:31
DavieySo since, the latest kernel, we haven't had an enviroment where we can reproduce that19:31
ttxDaviey: if you have bug numbers for those foundations issues, they can be raised in the release team meeting19:31
DavieyTherefore, i've been unable to provide further information OR confirm if the issue is still ongoing in the latest kernel19:32
jjohansenDaviey: so we know its kernel related, and not an update to something else19:32
ttxas blocking us.19:32
Davieyttx: That is what i'm spending all tommorrow attempting to triage19:32
ttxDaviey: ok, keep us posted if we need to escalate how blocking this is19:32
jjohansenDaviey: okay, the question came up as we were considering adding to the kernel teams top 5019:32
Davieyjjohansen: That bug is kernel related.. but due to other platform issues - it can't yet have an enviroment to attempt to triage/reproduce19:32
ttxDaviey: alpha1 was exhibiting the bug, right ?19:33
jjohansenDaviey: okay, keep me posted and I will recommend adding it to the top 5019:33
Davieyjjohansen: Yes19:33
ttxDaviey: so we could install alpha1 and reproduce it19:33
Davieyjjohansen: I'll update the bug and EOP tommorrow, with the current status19:33
Davieyttx: yes19:33
jjohansenokay, thanks Daviey19:33
DavieyHmm, alpha1 with current kernel might be an interesting experiment to see if it is fixed19:34
Daviey<-- /me will do that19:34
ttxDaviey: ping me if you need help -- I can spend some cycles on reproducing that19:34
Davieyttx: super, more hands the better19:34
ttxjjohansen: any progress on the atop patchset ?19:35
jjohansennot yeet19:35
ttxjjohansen: ok19:36
jjohansenany other questions for the kernel team?19:36
Davieyjjohansen: nothing server related from me, thanks!19:36
jiboumansjjohansen: do you think we can get some cycles on the atop patch in the next week?19:36
jiboumanswe have to present our alpha3 plan at the end of next week and atop would be part of that ideally, but only if you give it the thumbs up19:36
jjohansenjiboumans: yes19:36
jiboumansjjohansen: thanks, let me action that19:37
DavieyDo we have some ACTION's here?19:37
jiboumans[ACTION] jjohansen to review atop patchset for Alpha3 planning purposes19:37
MootBotACTION received:  jjohansen to review atop patchset for Alpha3 planning purposes19:37
jjohansenjiboumans: I'll see if I can't get you an answer on them by eob tomorrow19:37
jiboumans[ACTION] Daviey to update #588861, if needed against alpha119:37
MootBotACTION received:  Daviey to update #588861, if needed against alpha119:37
jiboumansjjohansen: that'd be great, but this week is good already19:38
jiboumansalright, thanks lads19:38
jiboumans[TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)19:38
MootBotNew Topic:  Weekly Updates & Questions for the Documentation Team (sommer)19:38
jiboumanssommer: first question is of course what can we help you with ?19:39
sommerI added some items to the blueprint: https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-serverguide-updates19:39
sommerbut I think the one I'll need the most help with is the UEC section19:39
jiboumansalright; daviey, kirkland, who of you would be up for taking that on?19:40
* kirkland points at Daviey 19:40
DavieyDepending on the UEC blocking stuff, i could spare some.19:40
sommerfor lucid I took the information from the wiki, so it would be great if someone could at least review what's  there19:40
kirklandsommer: Daviey there are a couple of good resources available for this already19:40
ttxsommer: deadline is ?19:40
kirklandDaviey: sommer: much has been written, just needs re-publication into the Server Guide format19:41
sommerttx: september 9th19:41
kirklandsommer: you can start with http://help.ubuntu.com/community/UEC19:41
DavieyCurrently UEC /doesn't work/ on Maverick.. I need to work on that first.. but after that i can spare some.19:41
jiboumanssommer: i'll edit the bp now, feel free to translate that to work items as appropriate19:41
DavieyOtherwise.. /me points at kirkland :)19:41
kirklandsommer: can you read through what we've written at that link above?19:41
* ttx would advise having those items for the beta iteration19:41
kirklandsommer: come back to us in a week or so, and let us know what you need more directly?19:41
kirklandsommer: based on what you need, i bet daviey and i can help19:41
* kirkland agrees with Daviey, UEC is busted in Maverick; that needs fixing first19:42
sommerkirkland: sure, I'd planned to, but only have two machines with the vt extensions19:42
kirklandsommer: you only need 1 to do UEC ;-)19:42
Davieysommer: two is plenty! :)19:42
jiboumanssommer: i see a few more items you need assistance wtih19:42
jiboumansshall we add some names to that list?19:42
sommerjiboumans: that'd be great, I planned on pinging ivoks about the clustering sections19:43
jiboumansclustering sounds like RoAkSoAx / ivoks indeed19:43
sommerttx gave me some updates for the Tomcat section a while back, but I can also test that19:43
jiboumanssommer: puppet(mathiaz) and tomcat (ttx) seem straight forward too19:44
ttxufw -> jdstrand19:44
sommerI'll ping soren about the vmbuilder stuff19:44
ttxvmbuilder -~~> soren?19:44
sommerhopefully get ahold of him at some point :)19:44
Davieysommer: Awesome, this is sounding like the best doc's yet!19:44
jiboumansthat leaves install tasks & opennebula19:44
ttxI'd drop opennebula, it's not really in our core cloud strategy19:45
sommeris opennebula widely used?19:45
sommerttx: sounds good to me19:45
* ttx never used it19:45
jiboumanssommer: there's some people experimenting with it19:45
ttxI think it's still universe ?19:45
jiboumanssommer: i couldn't speak to the state of opennebula on ubuntu right nwo though19:45
zulno i dont think so...afaik it still in unvierse and didnt build afaik19:45
* mathiaz agrees19:45
SpamapSwhat about documentation for pending MIR's ?19:45
mathiazsommer: I'd drop opennebula for maverick19:45
jiboumansit's the same as in karmic19:46
ttxSpamapS: ?19:46
sommermathiaz: sounds good will do19:46
jiboumanswhich is a minor patch on jaunty19:46
SpamapSttx: I'm not clear on what needs to be in the docs.. everything in main that is server related?19:46
jiboumansttx: are you ok with supporting sommer on documenting the new install tasks?19:46
mathiazSpamapS: not necessarly (actually not at all)19:46
ttxjiboumans: sure19:46
SpamapSOk, I've filed a few mir's .. mostly developer related stuff, not operational, so I don't think its necessary to document it either.. just wanted to make sure.19:47
mathiazSpamapS: we've got to decide what is *worth* putting in the server guide19:47
jiboumanssommer: could you please double check that the spec reflects the new reality? https://blueprints.edge.launchpad.net/ubuntu/+spec/server-maverick-serverguide-updates/+whiteboard19:47
sommerSpamapS: historically the serverguide has included items that will help an admin new to ubuntu to get up and running quickly19:47
sommerjiboumans: sure19:47
jiboumanson that note: edge.launchpad.net++ for having wider whiteboards19:48
* ttx hugs Bryce for unclutterring the whiteboard19:48
SpamapSok so the monitoring framework stuff for alpha3 may need some docs (though the spec is stil "pending approval")19:48
jiboumanssommer: i've added the names we just discussed; go ahead and change that to work items as appropriate. for the canonical guys, please schedule it for the beta iteration19:48
* kirkland high fives bryce too19:48
jiboumanssommer: for the others, whenever is good for them of course19:48
sommerjiboumans: will do19:49
jiboumansSpamapS: that'll be true until just before Alpha319:49
jiboumanswe don't 'approve' them until we've commited to work on them19:49
jiboumansand we decide that on a per-iteration basis19:49
* SpamapS continues absorbing the process19:50
jiboumanssommer: anything else from you?19:50
sommerI think that's it... thanks everyone for your help :)19:50
jiboumanssommer++ no, thank you19:51
jiboumans[TOPIC] Papercuts Alpha2 subcycle status (ttx)19:51
MootBotNew Topic:  Papercuts Alpha2 subcycle status (ttx)19:51
ttxquick status19:51
ttxall assigned19:51
ttx65% fixed19:51
ttxRemember to nominate for the next cycle19:51
ttxwe have a shortage in nominations19:51
jiboumansttx++ thanks19:52
* SpamapS has a couple in mind but cannot nominate for milestones.. yet19:52
jiboumans[TOPIC] Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)19:52
MootBotNew Topic:  Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)19:52
jiboumansSpamapS: tell ttx about 'm and he can nominate on yoru behalf19:52
ttxSpamapS: you can "nominate for papercuts"19:52
mathiazzul: what's the state of the weekly nomination script?19:52
SpamapSttx: right, right. :)19:52
ttxSpamapS: just mark as "Also affecting" server-papercuts19:52
mathiazzul: the WI is marked as done - I haven't seen an email going out though19:53
zulso the weekly nomination stuff is a work in progress19:53
mathiazone bug nominated for lucid: bug 58829319:53
ubottuLaunchpad bug 588293 in qemu-kvm (Ubuntu) "Memory leak" [Medium,Triaged] https://launchpad.net/bugs/58829319:53
mathiazanything worth SRUing on http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html ?19:54
SpamapShttps://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/419091  not on that list, but worth SRU'ing into karmic19:54
ubottuLaunchpad bug 419091 in couchdb (Ubuntu) "couchdb init script doesn't properly control processes" [Undecided,Fix released]19:54
zulmathiaz: bug 57241019:54
ubottuLaunchpad bug 572410 in samba (Ubuntu) "nmbd doesn't start because of missing testparm" [Medium,Fix released] https://launchpad.net/bugs/57241019:54
Davieypossibly 57958419:55
Davieybug 57958419:55
ubottuLaunchpad bug 579584 in libvirt (Ubuntu) "setgid, setuid needed by /etc/apparmor.d/abstractions/libvirt-qemu" [Medium,Fix released] https://launchpad.net/bugs/57958419:55
ttxSpamapS: karmic ?19:56
SpamapSttx: it was fixed in lucid, but karmic cannot stop couchdb.19:56
mathiazSpamapS: that's annoying19:56
mathiazSpamapS: if the patch is really simple it may be worth SRUing19:56
SpamapSthe init script was totally rewritten for lucid .. and would be a simple backport.19:56
mathiazSpamapS: hm - I've approved the nomination for now19:57
jiboumansSpamapS: the only real answer is: http://www.youtube.com/watch?v=Fow7iUaKrq4 #light-hearted19:57
jiboumansany other nominations?19:57
SpamapSjiboumans: ++19:57
jiboumans[TOPIC] New SRU Tracker (zul)19:57
MootBotNew Topic:  New SRU Tracker (zul)19:57
zulso for the maverick uds we are changing the way we do nominations for SRU...19:58
mathiazDaviey: does the bug fit the SRU criteria?19:58
jiboumans[LINK] http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html19:58
MootBotLINK received:  http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html19:58
zulwe are taking it to the ubuntu-server list to get more feedback, the email will be starting shortly after some introduction19:58
Davieymathiaz: possibly, requires more investigation19:59
zulwe are also monitoring the status of the SRU nominated bugs (work in progress) at http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html19:59
zulbasically its a cron job that sucks in launchpad into a sql database and displays the results19:59
zulit runs nightly so the information might be out of date sometimes20:00
mathiazzul: this is great work20:00
ttxThe results are slightly false though20:00
jiboumansi'd like to integrate this in our SRU reviews as well20:00
ttxI hear you have a fix for the "all boxes are green" issue20:00
zulttx: yeah because i havent worked out all the bugs yet20:00
jiboumansit's work in progress, but even the early version is helpful imho20:00
jiboumanszul: moving it to an LP branch a la work-item-tracker's good i think20:01
zulin the second table on that page is a list of nominated bugs that no one has worked on20:01
mathiazyes - we can already spot bugs that could handle some testing20:01
zulfunny that you mention that https://code.edge.launchpad.net/~zulcss/+junk/server-sru-tracker20:01
mathiazzul: of *accepted* bugs20:01
jiboumanszul: minues the +junk? :)20:01
zulbut it has to be moved to its own project20:01
zuljiboumans: ack20:02
jiboumanszul: indeed20:02
jiboumans[ACTION] zul to move the sru tracker code to it's own project20:02
MootBotACTION received:  zul to move the sru tracker code to it's own project20:02
jiboumanszul++ thanks for whipping this up20:02
jiboumansany more questions on the tracker?20:02
ttxyay, let's branch it20:02
zulttx: and mock the code? :)20:02
Davieyfork that.20:02
jiboumans[TOPIC] Open Discussion20:02
MootBotNew Topic:  Open Discussion20:02
jiboumansgoing once...20:03
DavieyNone here.20:03
jiboumansgoing twice...20:03
jiboumanssold to the bearded lady in the back20:03
jiboumans[TOPIC] Announce next meeting date and time20:03
jiboumansTuesday 2010-06-22 at 1800 UTC - #ubuntu-meeting20:03
MootBotNew Topic:  Announce next meeting date and time20:03
MootBotMeeting finished at 14:03.20:03
jiboumansthanks all20:03
sommerparty! :-)20:04
=== apachelogger_ is now known as apachelogger
=== kiko-fud is now known as kiko
czajkowskiAloha folks21:00
czajkowskiMeeting for loco council starting shortly21:00
MootBotMeeting started at 15:00. The chair is czajkowski.21:00
MootBotCommands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]21:00
czajkowskiAloha folks LoCo Council meeting on now21:00
czajkowski[link] https://wiki.ubuntu.com/LoCoCouncil/Agenda21:00
MootBotLINK received:  https://wiki.ubuntu.com/LoCoCouncil/Agenda21:00
czajkowskiThis evenings short agenda21:01
huatshello czajkowski !21:01
itnet7Hello everyone! :-)21:01
czajkowski[topic] Best Guide and Practices21:01
MootBotNew Topic:  Best Guide and Practices21:01
czajkowski[link] https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamsBestPracticesandGuidelines21:02
MootBotLINK received:  https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamsBestPracticesandGuidelines21:02
czajkowskiso just to make teams aware of a guide we've put together to help teams21:02
czajkowskiThe idea of this document is to help new teams set up and do some regular things that we have found work for teams21:03
czajkowskiIt;s broken down into monthly tasks21:03
czajkowskiif teams do monthly reports it gives you a good idea of what you are doing and if you aren't doing anything, then maybe you need a hand in coming up with some ideas21:04
* popey edits it a bit21:04
czajkowskiLong term goals to help you plan for the future, this can consist of helping and guiding new members21:04
czajkowskianyone have any questons21:04
czajkowskiitnet7: huats leogg care to join in21:05
itnet7czajkowski: I think you've covered it pretty well21:06
czajkowskiTHe guide has been translated but it'd be nice to see more translations21:06
huatsczajkowski, actually I agree with itnet7 it covers a lot of area21:07
czajkowskiThis is the first revision of it and perhaps at the end of this cycle we can review it if anyone has other ideas on what ideas do work for teams21:07
huatsI'll pass the URL to the french translation team21:07
czajkowskihuats: thanks :)21:07
czajkowskiok moving on so21:07
czajkowski[topic] LoCo Team Re Approval Update21:07
MootBotNew Topic:  LoCo Team Re Approval Update21:07
itnet7Maybe if anyone wants to suggest some ideas from the teams we can try and include them were feasible (sorry for the late feedback)21:08
czajkowski[link] https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval21:08
MootBotLINK received:  https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval21:08
czajkowskithe LoCo council has selected teams for this cycle to review.  It's random. Any team over 2 years is viewed.21:08
czajkowskiAs we cannot do every single team in one cycle we select a number, this time 3021:09
czajkowskiif you team is NOT ON THE LIST - you don't need to worry.  You will be selected another time21:09
czajkowskiDo not panic if you receive an email from us21:09
czajkowskiOne of the loco council members will contact you , that is your point of contact for the re approval process.21:10
czajkowskiIf you've any questions, just ask, if you want us to review your application before the meeting, just ask, We're here to help you21:10
czajkowskiDoes anyone have any questions regarding the process?21:10
czajkowskihmm not sure the silence is good, as there does seem to be a bit of confusion regarding this on the mailing list.21:11
popeyI suspect not many loco team members are here21:11
czajkowskipopey: possibly.21:11
itnet7that's what I was thinking as well21:12
YoBoYi'm here ;)21:12
czajkowskiwonder do they know it's on21:12
czajkowskiYoBoY: aloha!!! :)21:12
popeyI dont think they care :(21:12
YoBoYhi :)21:12
czajkowskipopey: aye I think it's more of a case of they're not sure what this meeting is for, is it just for re approval meetings21:13
czajkowskipopey: I think this is something we should be looking into21:13
huatsof course you are here YoBoY :)21:13
czajkowskiI'll move onto the next topic as that's kinda more inline with it21:14
czajkowski[topic] How the LoCo Council can help you21:14
MootBotNew Topic:  How the LoCo Council can help you21:14
czajkowskiI guess the fact that there are very few team members here is something we should looking into21:14
czajkowskiI don't think LoCo teams know about this meeting, and if they do know it exists, they assume it's only for approval and re approval meetings21:14
AlanBelldo you want team members here or point of contacts?21:15
huatsI think both would be great :)21:15
czajkowskiAlanBell: it's welcome to everyone. anyone who wants to learn more about the community, or take part in discussion21:15
czajkowskiIf the point of contacts are here, it would be great as they could/should be passing on information to their teams21:16
czajkowskias I have noticed many point of contacts not explain the re approval process to their teams21:16
popeywe know they dont do that though21:16
popey(pass information on)21:16
popeyfrom the loco-contacts list for example21:16
czajkowskipopey: :( aye we do now21:16
mhall119do meeting minutes get sent to loco-contacts?21:16
czajkowskimhall119: we started doing that last cycle21:16
mhall119ok, I couldn't remember seeing any21:17
czajkowskiSo how can we get more teams to come here and take part21:17
czajkowskihow can we make sure point of contacts are in fact passing on information to their teams21:17
itnet7czajkowski: you can mention it in your checkup talks, and we can blog about it21:18
czajkowskiwhich is the whole point of a point of contact21:18
czajkowskiitnet7: aye I think we the council should be blogging about this issue21:18
AlanBellwell, it being a "loco council meeting" kind of led me to believe it was for the loco council to attend (plus teams under reapproval)21:18
czajkowskiThere are 6 of us, so I think we should be able to increase the awareness of this21:18
huatsczajkowski, I agree21:18
huatsAlanBell, it is a LoCo Council meeting. So it is a meeting where you can find the LoCo Council... and not leave them alone :)21:19
czajkowskiIt's also a chance to raise issues and bring them to our attention21:19
czajkowskifolks find us on IRC the whole time, but it would be nice to have them rasied here so more input can be made21:20
YoBoYi can't remember if you send an email to the loco ML to remember this meeting and invite them to come21:20
huatsYoBoY, no I don't think either21:20
czajkowskiYoBoY: that's true we should do that21:20
huatsczajkowski, I can blog about it21:20
popeyso we need to change perception of the meeting, and better communicate the purpose of it?21:20
czajkowskipopey: yes21:20
huatspopey, +121:20
popeyyet more reason for us to mail all the loco teams mailing lists?21:20
huatspopey, indeed...21:21
czajkowskiSo how about on the Monday before the meeting we mail the loco contacts mailing list to poke them and let them know this meeting is on and to add agenda items ??21:21
huatsczajkowski, you mean the day before ?21:21
czajkowskihuats: aye is that too short?21:21
popeywe already know people a) dont read the loco contacts list, and b) people dont pass it on21:21
AlanBellperhaps communicate to the point of contacts that their attendance or the attendance of a representative from their loco is expected21:21
huatsa bit short I think21:22
popeyso i'm unconvinced how effective that would be21:22
czajkowskiperhaps we could ask jono to blog about this21:22
huatsI would prefer the friday before21:22
czajkowskipeople do read his blog and his tweets21:22
=== GoBrazil is now known as Ursinha
popeyI am also unconvinced blogging is the way forward21:22
czajkowskiis jono around, before I action him stuff21:22
czajkowskipopey: ok, what would you suggest?21:22
mhall119I might have some suggestings that tie into the next agenda item21:22
popeyi dont think we should be actioning anyone without figuring out the problem / solution first21:22
huatspopey, well I think it is not a big action to blog and mail21:22
huatswe can try out to see it there is any improvment :)21:23
popeyok, here's my thoughts..21:23
czajkowskipopey: I think the lack of awareness is a large issue21:23
huatspopey, go ahead :)21:23
popeydo we really need people to be here to listen to us announce a wiki page?21:23
popeysurely this can be better communicated via other means than irc21:23
mhall119I think the desire is for the LC to listen to team members, not the other way around21:23
popeysure, which brings me onto my next point21:24
popeythey know where to find us, we have a mailing list, and people do use it21:24
popeyof course if they want to discuss stuff we can do so in irc21:24
popeybut it's not like we're inaccessible?21:24
popeyor are we?21:24
huatspopey, actually you are :P21:25
czajkowskipopey: thats true, however, tis kinda hard to follow up on a pm, and folks only seem to poke the same people over and over21:25
czajkowskipopey: not all of us are on IRC or run screen sessions so we get messages21:25
mhall119itnet7 keeps spending time on someting called "work"21:25
itnet7mhall119: :-p21:25
huatsI think the clear misunderstood of the reapproval that people had faced lately and the number of email our mailing list received is quite explicit21:26
czajkowskiI'd rather see teams coming here and engaging in discussion21:26
paultagHey. Sorry I'm late21:26
czajkowskithere seems to be a lack of discussion happening here and even on the mailing list21:26
huatson the other hand I have been quite suprised to see a team asking where to find me...21:26
czajkowskipaultag: welcome :)21:26
YoBoYhi paultag21:27
czajkowskiYoBoY: AlanBell mhall119 you're the only ones who are active here atm. What would you like to see happening? to get discussions going?21:28
mhall119well, this kind of ties into the meeting feature we're talking about for loco-directory21:29
AlanBellwell I had no idea I didn't have to shut up :-)21:29
mhall119since loco-council in in the directory, it will be able to add meetings there, and add other teams to those meetings21:29
paultagHey! Quiet-pants! Let's get some talk going or we might as well stop here!21:29
itnet7popey: may be on to something though, maybe we can use the LoCo Health Check meetings to discuss all of the resources and keep this meeting aside for re-approvals21:29
paultagduanedesign: POKE! You're quite active in the community :)21:29
paultagJoeb454: Ya'here?21:29
itnet7not everyone would have to attend both21:29
czajkowskiakgraner: where are you, you're usually a lot more active21:29
czajkowskiitnet7: good point21:30
mhall119if we can get teams using ical feeds from LD to advertise meetings to their members, then the loco-council can get on those ical feeds for each team too21:30
czajkowskiitnet7: at present folks just attend here for approvals21:30
czajkowskimhall119: *nods*21:30
mhall119czajkowski: she said something in ubuntu-us-nc earlier about not being around as much due to surgery on her arm, but I'm not sure if that's happened yet or not21:30
czajkowskimhall119: would this be also like the UWN ( akgraner ) with the icals for meetins?21:30
AlanBellI just think a "who should attend" line somewhere might be useful21:30
YoBoYdon't know... the re approval process is in its way for our locoteam, the wiki explain a lot, i haven't questions aout it yet21:30
AlanBellon the agenda21:30
mhall119czajkowski: UWN has a ical feed?  or do they want an ical feed?21:31
akgranerczajkowski, you are making my machine blink :-)  what's up?21:31
itnet7Well I mean if one or two of the LC members can support each other for the Health Check and we can focus on having a quorom here for the re/approvals that may be a good solution21:31
czajkowskithey are doing them21:31
paultagjacob: cjohnston, drubin, nigelb, Poke, ya'll -- We need some more talk on LoCo stuff. You guys around?21:31
czajkowskiakgraner: wondeing why folks we know are active are not active in this session21:31
mhall119czajkowski: since akgraner asked me for the meeting feature, I guess it would probably replace what UWN is doing21:31
akgranerahh I am publishing the newsletter at the moment :-)21:31
cjohnstonme too21:32
popeynice timing21:32
akgranermhall119, nope won't replace what we do in UWN but it will give me a place to point people to for LoCo information21:32
mhall119ah, ok, what do you have ical feeds for now?21:32
drubinpaultag: yes21:33
czajkowskiok so I think at least as a start we should be mailing the loco contacts mailing list the Friday before the meeting to REMIND them it's on.21:33
czajkowskiI'll take that on21:33
paultagdrubin: thanks :) -- LoCo council meeting, it's quiet. Can I convince you to stick around and throw your two cents in?21:33
akgranerUWN will report the development team meetings, move the LoCo meetings off the Fridge calendar and on to a LoCo Calendar instead21:33
czajkowski[action] czajkowski to mail loco contacts mailing list the Friday before the meeting to remind people this meeting is on21:33
MootBotACTION received:  czajkowski to mail loco contacts mailing list the Friday before the meeting to remind people this meeting is on21:33
mhall119akgraner: okay, I understand now21:33
drubinpaultag: sure I need to read the scroll back quick though21:33
paultagczajkowski: I should have CC'd contacts when I mailed the council ML21:33
paultagdrubin: quite alright21:34
akgranermhall119, awesome! :-)21:34
czajkowskipopey: moving forward what would you suggest? for communication methods?21:34
popeyI'm not sure, I wanted us to discuss it, rather than just say 'lets blog it'21:35
popeyfigure out what the best way forward is.. if that makes sense21:35
huatspopey, makes sense21:35
itnet7definitely popey21:36
AlanBellfwiw I am unconvinced that blogging it is the solution, it won't be seen by people who are not yet involved in Ubuntu21:36
czajkowskipopey: well I'd love to see discussions take place on the list21:36
popeyAlanBell: I am not sure they are target audience anyway21:36
paultagAlanBell: well we are only worried with talking with contacts21:36
czajkowskiI also btw tweet using #locoteams as do very few others, but it's interesting to follow and something we could push21:36
paultagAlanBell: contacts talk with lay members :)21:36
popeytarget is people who are already in loco teams, who need help, mentoring, direction etc21:36
paultagczajkowski: I like that21:36
huatsczajkowski, good idea too21:37
czajkowskipopey: true21:37
drubinczajkowski: Nice idea.21:37
czajkowskipopey: I think we need to increase the awareness of this Council also - that it's not taboo to contact us.21:37
huatspopey, I do beleive that people who are involved in LoCo teams are quite exposed to planet ubuntu21:37
paultagWonder if we could have a tweet version of planet ubuntu21:37
czajkowskiIf folks know they can contact us about anything, bouce a loco idea off us or just need a hand, we're here to help21:38
czajkowskipaultag: no!21:38
huatspopey, I am not saying it is THE solution, but cool be part of it21:38
paultagczajkowski: it will support identi.ca too!21:38
huatspopey, I meant can be part of it21:38
mhall119paultag: status.net21:38
paultagmhall119: well it's all the same API21:38
popeyok these are technical details21:39
AlanBellpopey: what I meant was that blogging is a point in time and the community is growing so new people won't see today's blog entries21:39
mhall119paultag: but status.net can have separate domains21:39
popeythe main issue is getting information out to members of locos around the world21:39
paultagmhall119: another issue21:39
paultag+1 popey21:39
huatsAlanBell, of course21:39
czajkowskipopey: +121:39
mhall119paultag: you can ask akgraner about it21:39
drubinpopey: I think a biggest issue is gettting the info out to the rest of the people.21:39
paultagmhall119: we'll do that after the meeting if that's the direction we go with :)21:39
drubinI think ubuntu hour was one of the greatest things our loco ever did.21:40
czajkowskipopey: is it something we should be mandating points of contacts to pass mails from us to loco contacts list to their teams list21:40
paultagdrubin: Yes!!!21:40
czajkowskisomething that the loco council should indeed be mailing LoCo teams mailing list wiht21:40
drubinIt has started up a Lug in our area to have their beer evenings again!! it was awsome21:40
czajkowskiI know this kinda topic came up at UDS21:40
drubinpaultag: More global jams and bug things21:40
popeyI still think we should mail out to all the loco mailing lists21:41
paultagczajkowski: Humm. Could we set up something fancy with launchpad RE the approved team list, and CC that list ( which will send to all lists )21:41
czajkowskishould the loco council post to the Teams mailing list information we want teams to have for definate ie, re approval??21:41
paultagpopey: me too21:41
mhall119czajkowski: I'm gonna need to leave in about 15 minutes, will there be time for my agenda item?21:41
drubinlike I know when there is a global thing my loco gets excited and wants to be involved but if it is just SA they aren't so keen21:41
AlanBelldo you think there should be a "who should attend" section on https://wiki.ubuntu.com/LoCoCouncil/Agenda21:41
popeyyes al21:41
czajkowskiAlanBell: yes21:41
czajkowskipopey: see my comment above21:41
YoBoYdrubin: you can organize that without the global event thing ;)21:41
czajkowskimhall119: should be21:42
akgranerpaultag, let me get UWN published - and I'll be happy to answer question about status.net :-)21:42
drubinYoBoY: you missed my point, when it is global people are always more keen! :)21:42
paultagakgraner: we'll do it after the meeting, deal?21:42
drubinand yes we do.21:42
paultagakgraner: :)21:42
YoBoYdrubin: ok21:42
huatsczajkowski, I think we cannot completly rely on loco contacts21:42
huatswe have seen that of a few occasions lately21:42
drubin;/ that is sad21:43
paultaghuats: I agree21:43
czajkowskihuats: what about for imporatn mails, we actually mail the loco mailing list itself, ie we'd mail all the teams approved and unaproved with issues we want to bring to their attention21:43
czajkowskiso ireland france uk would get the mail from us21:43
paultagoi oi, Ohio too!21:44
mhall119everyone except Ohio ;)21:44
drubinas long as it is low traffic21:44
czajkowskipaultag: I wasn;t going to list all of the teams out! I'd be here all evening my dear!21:44
paultagdrubin: +1, and major stuff :)21:44
paultagczajkowski: :)21:44
czajkowskidrubin: it'd be only for important mails21:44
drubin90% of the stuff on loco-contacts is useless for most locos21:44
huatsczajkowski, this is something we have envisaged : to have a direct access to loco mailing list21:44
drubinczajkowski: Just making it noted but ye I assumed it would be21:45
czajkowskiwell it'd take us the loco council being added to all of the teams21:45
czajkowskidrubin: :)21:45
paultagczajkowski: could we sneak something with the launchpad group?21:45
czajkowskipaultag: leave lp alone :p21:45
paultagczajkowski: we already have a list, maintaining it is hard IMHO21:45
drubinalso just so you know that most of the teams don't use LP for thier mailing lists21:45
paultagczajkowski: well shucks, it would save us time!21:45
czajkowskipopey: would it take much for us to be added to all of the teams ??21:45
paultagdrubin: I know, but if their contact addy was the ML we would be all set21:45
popeyit would just take 5 mins subscribing to each mailman list21:46
paultagdrubin: us --> lp --> lp teams --> lists.ubuntu for each team21:46
popeyand set them all to nomail21:46
popeyso we dont get all their mail, we just send mail to their list as a subscriber21:46
drubinwell maybe it would be better to subscribe the council to each team.21:46
AlanBellagenda fixed.21:46
czajkowskiok, how does that sound to the council, going forward for important mails and annoucements we send our mail directly to the teams ??21:46
paultagI'll +1 it, even though it's more work :)21:47
popeyI'd check thats okay with jono / the cc21:47
popeyits not much work tbh21:47
paultagI'm kidding popey :)21:47
huatsczajkowski, +1 for me too21:47
paultagI'm all for it. I think it would help a lot21:47
paultagJust worried about RE mail, but that is OK.21:47
itnet7sounds good to me21:47
czajkowski[action] popey to investigate The LoCo Council being added to all LoCo teams mailing list so the Council can post directly to them21:47
MootBotACTION received:  popey to investigate The LoCo Council being added to all LoCo teams mailing list so the Council can post directly to them21:47
huatspopey, you are right to ask for it with CC and jono21:47
drubin+1 fro popey21:47
czajkowskiok does anyone have any further comments as I'd like to move onto mhall119 topic please21:48
drubinany thing >1 per month IMHO is to high trafficthough21:48
czajkowski[topic] LoCo-Directory Meeting Feature21:48
MootBotNew Topic:  LoCo-Directory Meeting Feature21:48
czajkowskimhall119: you're up21:48
mhall119thanks czajkowski21:48
czajkowski[link] https://wiki.ubuntu.com/LoCoDirectory/MeetingFeature21:49
MootBotLINK received:  https://wiki.ubuntu.com/LoCoDirectory/MeetingFeature21:49
mhall119so, after releasing the event tracking feature on loco.ubuntu.com, we've had several people ask us about using it to track IRC meetings21:49
* mhall119 is one of the loco-directory devs21:49
mhall119the current event feature is really specific to physical meetups, so we're looking into creating an IRC meeting feature to compliment it21:49
mhall119this feature would let teams schedule meetings, give the channel they will be held in, provide a structured list of agenda items, etc21:50
mhall119it would largely replace the use of Wiki pages for these things21:50
mhall119wiki pages would still be used to expand in detail on specific agenda items21:50
mhall119once we have all this data in a structured form, we can produce ical feeds, give it to Mootbot directly, and automatically link to logs and minutes21:51
AlanBellI am working on an improved mootbot framework in this cycle which would do nice automated mintues, it could integrate directly with the loco directory to read agenda items and publish minutes and action points back21:51
czajkowskiSo I asked mhall119 to bring this up onthe list - but there was silence on it.  Just because I don't think it's very fair if one team makes a suggestion for this and then it gets implemented and all teams now have to use it. Then information is on the wiki and on the LD21:51
paultagI'm here, but eating dinner. Don't mistake me for missing!21:52
huatsok czajkowski21:52
huatsyou were right to do so21:52
mhall119we wouldn't force teams to use this feature instead of the wiki, but once more and more people are using it as a source of data, they will likely feel compelled to do so21:52
czajkowskiI also think that by adding more and more features to replace the wiki, teams may not be confortable with this and then information is all over the place21:53
czajkowskimhall119: so that;s kinda forcing people by the fact that most do.21:53
AlanBellthe mootbot changes would have to be backwards compatible and also wiki optimised as the loco directory only does loco teams, all other teams that hold meetings would not be helped by this21:53
mhall119so far the reception to the events feature has been very positive21:53
paultagmhall119: can you talk with wiki?21:53
czajkowskiAlso for the council to review teams, to have information in one place and not all over the place does help21:53
mhall119paultag: not really, because wiki's aren't structured21:53
paultagmhall119: perhaps we can have loco-directory write to /loco-direcotory/automated/team/event/21:53
paultagmhall119: and from there include it on the page of the team21:53
mhall119we could post to a wiki, I suppose, but not reliably read from it21:53
paultagmhall119: all you have to work out is how to auth21:54
paultagmhall119: you don't need to read21:54
mhall119then yes21:54
mhall119or a Moin macro can be made to retrieve data from the directory and format it for the wiki21:54
paultagmhall119: perhaps move it all to loco-directory that way21:54
czajkowskiI think what mhall119 wanted to know and see was if teams would use this. But I don;t think there are enough people to really discuss this either21:54
mhall119now, to go back to the previous discussions, since loco-council is one of the teams loco.ubuntu.com is aware of, they can post their meetings there too, and include other teams in those meetings21:55
paultagczajkowski: hopefully it won't impact teams that don't use it21:55
mhall119also, for reapprovals, the loco-council could schedule the meeting and include each team that is up for re-approval21:55
mhall119it won't directly impact teams that don't use it, but if most teams do use it, the teams that don't may miss out on new features21:56
mhall119I don't think that's really forcing them though, just offering a better option21:56
mhall119as long as Mootbot can continue to take manual direction21:56
mhall119it shouldn't interfere with their current methods21:57
czajkowskimhall119: hmm my objection still stands though. Team members getting developers to work on this is great, but no discussion with teams and then implementing it, isn't very community driven either21:57
mhall119but, it would mean akgraner would have to pull from loco-directory and the wiki for UWN21:57
mhall119czajkowski: I agree, and I would like to see more discussion about it21:57
paultagmhall119: well right now we have 100% of the teams on the wiki21:57
popeycreating it is fine, forcing it on locos isnt czajkowski, i agree21:57
mhall119unfortunately there's just been a lot of silence21:57
paultagmhall119: we are going to work on migrate, but it takes time, and we can't rush new things21:57
drubinmhall119: btw you have made some assumptions like only using freenode. not being able to use it for physical meetings, not having a list of people present21:57
mhall119we've had several requests for the feature, and one complaint21:58
czajkowskipopey: right, which is what is gonna happen :(21:58
czajkowskimhall119: I've also seen no discssion either21:58
mhall119drubin: yes, feel free to bring those up in the spec, it's still in the planning stage21:58
czajkowskimhall119: my complaint is that disussion hasn't happened21:58
mhall119czajkowski: understood, I'm trying to change than21:58
czajkowskimhall119: I know21:59
huatsczajkowski, but I fear that there might have no discussion...21:59
mhall119my feeling is, if there is little interest, no objection, and a lot of indifference, that's enough to justify doing it21:59
czajkowskihuats: so we're back at tonights earlier topic :)21:59
czajkowskimhall119: :o21:59
AlanBellI am unsure why there is a concern about this being forced on teams22:00
huatson another hand I thik that sometimes the discussion starts once someone is trying to use it, so it needs to be done... (but I assume it is not the right way to do stuffs)22:00
mhall119the biggest impact would be on akgraner and UWN, as they would have to pull from two sources if teams continued using the wiki22:00
paultagthat's not true mhall11922:00
drubinthe point about scrum and stories is developsomething small, and interate.22:00
drubinif it doesn't work change it22:00
paultagmhall119: you can not pull from the loco-directory, only pull from the loco directory or both22:01
mhall119I don't follow22:01
paultagmhall119: I like the loco-directory, but we need to work on a slow migraton. For now the Wiki is the most upto date source22:01
czajkowskimhall119: fair enough but I don't think we should change based on UWN either. Some teams like wikis and tbh, most teams aren't useing the LD as much as they could22:01
paultagmhall119: that's why I'm thinking a wiki bridge might aid in adoption22:01
czajkowskiI'd rather see more of a focus getting teams to use the LD and posting events to it22:02
czajkowskibefore meetings22:02
drubin+1 from my side22:02
huatsczajkowski, I agree22:02
mhall119paultag: would we be allowed to add a Moin macro to the Ubuntu wiki servers?22:02
drubinthere seems to be an perception that it is hard to post an event22:02
czajkowskihuats: I think the focus for this cycle should be getting teams to use the LD, adding their events and detals on it22:02
drubinor even sign up to an event22:02
paultagmhall119: perhaps, but it's really easy to do it the other way -- why not just write to wiki pages22:02
czajkowskiand not meetings22:02
mhall119drubin: how so?22:03
paultagmhall119: just set up /loco-directory/automated/ blah blah22:03
huatsczajkowski, I agree with you22:03
mhall119paultag: we would need to authenticate to the wiki22:03
czajkowskihuats: :)22:03
paultagmhall119: trivial22:03
drubinmhall119: I have no idea just does ;/22:03
mhall119paultag: okay then, would you help us with that part?22:03
drubinmhall119: I am not saying I feel that it is the feeling I get from other people22:03
huatsczajkowski, so it might be worth putting an effort on developping an early version of the meetings :) and improve it while team start using it on the next cycle22:03
drubinOk but I need to get going.. sorry I couldn't stay the full meeting, but I think emailing the loco-contacts before the meeting would help.22:05
czajkowskidrubin: ok we;ll be doing that in future22:05
paultagty drubin22:05
czajkowskidrubin: thanks for coming22:05
mhall119I need to head out too, are there any questions I can answer before I go?22:05
mhall119feel free to keep discussing it after I'm gone, I'll read the logs from home22:06
paultagmhall119: can you work out the practical way of briding wiki and ld and get back to us?22:06
mhall119paultag: as long as the intention is to move forward with this feature if such a bridge is made22:07
mhall119otherwise it'd just be a waste of time22:07
paultagmhall119: it is22:07
AlanBellpaultag: not entirely sure it needs to do that, if mootbot could publish both to the wiki and to the LD then doesn't that solve it?22:07
mhall119ok, I will ask you later how to get LD authenticating to the wiki22:07
paultagAlanBell: well if the events on a wiki page for a team was pulling from LD it would be more up to date then anything else22:07
AlanBelland yeah, I have no idea how to do the auth bit22:07
czajkowskidoes anyone else have any comments ?22:07
paultagmhall119: thanks rockstar22:08
AlanBellpaultag: ah, ok for the events bridge, gotcha.22:08
paultagAlanBell: aye22:08
mhall119I'm in #ubuntu-locoteams or #ubuntu-us-fl all the time if anybody has other questions22:08
mhall119otherwise, put your ideas/concerns on the spec page22:08
czajkowskimhall119: thanks22:08
mhall119thanks everybody22:08
paultagty mhall11922:09
huatsthanks everyone22:09
czajkowskiHas anyone else got any other topics for the loco council ??22:09
czajkowski[action] paultag write up mins and post to contacts mailing list and update wiki22:09
MootBotACTION received:  paultag write up mins and post to contacts mailing list and update wiki22:09
MootBotMeeting finished at 16:09.22:09
czajkowskipaultag: in case you think I'd forgotten22:10
paultagczajkowski: :P22:10
popeyi expected us to be here for another hour  :)22:10
czajkowskipopey: I can restart meeting if you;ve other items ?22:10
paultagWell, I'm off to cut my lawn. Thanks, all!22:12
=== DarkwingDuck_ is now known as DarkwingDuck
=== apachelogger is now known as fluffymaster
=== Ursinha is now known as Ursinha-fud

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