[11:59] <dholbach> mako, Technoviking, popey, pleia2: around?
[12:01] <popey> o/
[12:01] <dholbach> JeffWaugh     May I add Ubuntu's Bleeding Edge to PlanetUbuntu?     11 UTC
[12:02] <dholbach> is the only agenda item - I'm happy to follow up on that via email
[12:02] <dholbach> hi popey - is there anything else we should talk about?
[12:04] <popey> not that I can think of
[12:05] <popey> kubuntu council?
[12:05] <dholbach> ah yes, I need to follow up on that thread too
[12:05] <dholbach> mako, Technoviking, popey, pleia2: ^ feel yourself poked about this :)
[12:05] <dholbach> also I'll talk to mdke about the wiki licensing again
[12:06] <dholbach> but that's all I can think is on our agenda
[12:06] <dholbach> "agenda"
[12:06] <popey> indeed
[12:06] <dholbach> alright, I'll go and send a few mail, update the team report, etc.
[12:06] <dholbach> Adjourned. :)
[12:07] <jussi> wow, that was quick..
[12:07] <popey> dont blink!
[12:08] <popey> great, I can go to lunch now :)
[12:08] <dholbach> popey: bon appetit
[14:00] <NCommander> #startmeeting
[14:00] <MootBot> Meeting started at 08:00. The chair is NCommander.
[14:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:00] <davidm> G'day NCommander
[14:00] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100615
[14:00] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100615
[14:00] <NCommander> ogra: GrueMaster dyfet ping
[14:00] <NCommander> davidm: morning
[14:00]  * ogra refuses to take part in a meeting that wasnt announced :P
[14:00]  * GrueMaster mumbles
[14:00] <ogra> (you forgot the mail again) :)
[14:01]  * NCommander coughs 
[14:01] <NCommander> [topic] Action Items from June 8th, 2010
[14:01] <MootBot> New Topic:  Action Items from June 8th, 2010
[14:01] <NCommander> [topic] NCommander to discuss build timeout with lamont
[14:01] <MootBot> New Topic:  NCommander to discuss build timeout with lamont
[14:02] <NCommander> I discussed it with him, but before we came to a conclusion, the troublesome package (qt4-x11) magically started building again ...
[14:02] <NCommander> so its fixed, though we're not sure why
[14:02] <ogra> well, we still need a proper solution for that
[14:02] <ogra> its not only one package that times out
[14:02] <NCommander> ogra: lamont has made it so its easier to update the build timeouts then before, so it can be changed with less pain
[14:03] <ogra> hmm, k
[14:03] <NCommander> [topic] NCommander to poke Keybuk on libnih
[14:03] <MootBot> New Topic:  NCommander to poke Keybuk on libnih
[14:03] <NCommander> libnih 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 Items
[14:03] <MootBot> New Topic:  Standing Items
[14:03] <ogra> err
[14:03] <NCommander> ogra: ?
[14:04] <ogra> libnih cant build because upstart ftbfs
[14:04] <ogra> be sure it will return
[14:04] <NCommander> oh, d'oh. why isn't it on the depwait list then :-/
[14:04] <NCommander> c/o on that item then
[14:04] <NCommander> [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html
[14:04] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html
[14:05] <NCommander> We're making progress
[14:05] <ogra> http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-2.html would be more intresting though
[14:05] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-2.html would be more intresting though
[14:05] <ogra> given thats our next milestone
[14:06] <ogra> if we get 4 todos done in that we'll look good for A2
[14:06] <ogra> 5 would be even better :)
[14:06] <NCommander> indeed
[14:07] <NCommander> I refactored and cleane dup the preinstalled d-cd branch last night, so its good for initial merging
[14:07] <ogra> great
[14:07] <ogra> give me something to review later today
[14:07] <GrueMaster> How close are we to having daily images?
[14:08] <ogra> debian-cd merge, cdimage merge of the publisher scripts
[14:08] <NCommander> GrueMaster: jasper needs to go in archive, we need an MIR, and I need to finish compressed image support
[14:08] <ogra> and some jasper fixes
[14:08] <GrueMaster> ok
[14:08] <ogra> NCommander, jasper is in the archive since 2 weeks
[14:08] <NCommander> ogra: d'oh
[14:08]  * NCommander dons dunce cap
[14:08] <ogra> but i cant test it without a working kernel
[14:08] <ogra> (which brings us to next topic i guess)
[14:08] <NCommander> I thought we had a working OMAP 3 kernel
[14:09] <GrueMaster> Not that I have seen.
[14:09] <NCommander> [topic] Kernel Status (cooloney, mpoirier)
[14:09] <MootBot> New Topic:  Kernel Status (cooloney, mpoirier)
[14:09] <ogra> the .34 omap3 kernels did work
[14:09] <ogra> with the switch to .35 they broke
[14:09] <mpoirier> i have yet to test.
[14:09] <mpoirier> should get to it today.
[14:09] <ogra> GrueMaster, where is the bug you wanted to file yesterday ?
[14:09] <mpoirier> in any case,
[14:10] <mpoirier> about SD card ?
[14:10] <ogra> no
[14:10] <GrueMaster> 594382
[14:10] <ogra> bug 594382
[14:10] <mpoirier> haven't looked at it.
[14:10] <mpoirier> still on SD card.
[14:10] <GrueMaster> Oh, on the sd card.   I'll have to look
[14:10] <GrueMaster> I don't have it up atm.
[14:11] <mpoirier> fine, I'm looking at code at this time and can reproduce on my rig.
[14:11] <GrueMaster> bug 592688
[14:12] <mpoirier> yes, that is the one.
[14:12] <GrueMaster> Should I assign those to you?
[14:12]  * ogra comments on the bug and adds some pointers
[14:12] <ogra> (the daisy chain one)
[14:12] <davidm> mpoirier, you need an OMAP3 board correct?
[14:12] <mpoirier> I suppose you could.
[14:13] <mpoirier> Well, I could use a bb C4.
[14:13] <mpoirier> have C2 atm.
[14:14] <davidm> I'll send a C4 out today
[14:14] <mpoirier> very well thank you.
[14:14] <ogra> DavidLevin, do we still have spare XMs ?
[14:14] <ogra> err
[14:14] <ogra> davidm, ^^^
[14:14] <ogra> since i see massive issues there too with the curent omap3 kernel
[14:14] <davidm> ogra, I have 1 unit now
[14:14] <ogra> i think lag has one
[14:15] <davidm> I can ship that if you need it.
[14:15] <ogra> well, lag, amitk and me each have one unit, depends if mpoirier will work on XM issues too
[14:15] <davidm> NCommander, give me an action to ship mpoirier a C4 this week please
[14:15] <ogra> then it would make sense to ship one to him
[14:15] <NCommander> [action] davidm to ship mpoirier a beagle C4
[14:15] <MootBot> ACTION received:  davidm to ship mpoirier a beagle C4
[14:15] <davidm> NCommander, also add ship mpoirier a XM too
[14:16] <NCommander> [action] davidm to ship mpoirier a XM board
[14:16] <MootBot> ACTION received:  davidm to ship mpoirier a XM board
[14:16] <ogra> great
[14:16] <davidm> I think I'll cry, every time I get hardware I have to ship it out.....
[14:16] <GrueMaster> heh
[14:16] <ogra> heh
[14:17] <ogra> lag, any news about omap4 ?
[14:17]  * NCommander gives davidm a Babbage board
[14:17] <lag> News?
[14:17] <ogra> well, we're waiting for a binary package in teh arm team :)
[14:18] <lag> I have a working build
[14:18] <ogra> do you know whats the progress there is ?
[14:18] <lag> But I didn't build it
[14:18] <lag> I'm afraid cooloney is your man
[14:18] <ogra> yeah, i'm more intrested about something in the archive :)
[14:18] <lag> Nothing as yet
[14:18] <lag> AFAIK
[14:18] <ogra> ok
[14:19] <ogra> NCommander, move ?
[14:19] <NCommander> [topic] QA Status (GrueMaster)
[14:19] <MootBot> New Topic:  QA Status (GrueMaster)
[14:19] <GrueMaster> I have been doing a lot of testing and retesting of the image ogra handrolled last week on various sd cards.
[14:19] <ogra> GrueMaster, could we have a list of milestoned bugs on the meeting agenda ?
[14:20] <ogra> that would help a lot with the release meetign preparation and with keeping an easier overview
[14:20] <GrueMaster> I can add them later today.
[14:20] <ogra> only the critical and high ones that are milestoned
[14:20]  * GrueMaster needs coffee still.
[14:20] <GrueMaster> Ok.
[14:20] <ogra> should only be a few each week
[14:20]  * NCommander needs that magicial substance as well
[14:21] <ogra> NCommander, move ?
[14:22] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, dyfet)
[14:22] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, dyfet)
[14:22]  * NCommander has nothing to report since he hasn't had time to work on this
[14:22] <dyfet> Well, there are some items pending from upstream
[14:22] <dyfet> (glib2.0 and gobject introspection)
[14:22] <dyfet> I did work on others though as well, and did btrfs-tools
[14:23] <ogra> did you tak to seb128 about glib ?
[14:23] <dyfet> Yes
[14:23] <ogra> *talk
[14:23] <ogra> ok
[14:23] <dyfet> Thats why I did not submit my patch for it
[14:23] <ogra> anything NCommander or i need to sponsor ?
[14:24] <dyfet> I sponsored with rainct :)
[14:24] <dyfet> I may have openmpi resolved later today, but I know we need to get kde unstuck
[14:24] <ogra> can you make sure your name shows up in the uploads ?
[14:25] <ogra> else sponsored uploads wont help you with MOTU
[14:25] <dyfet> ok
[14:25] <dyfet> true :)
[14:25] <dyfet> I had to pass on glib2 since there was an upstream fix being merged...
[14:26] <ogra> what about compiz ?
[14:26] <dyfet> I can look at that later tonight or tomorrow
[14:26] <ogra> and xscreensave seems to have failed too
[14:27] <ogra> the rest looks like glib or qt fallout
[14:27] <dyfet> ok
[14:28] <NCommander> [topic] ARM Image Status (ogra, NCommander)
[14:28] <MootBot> New Topic:  ARM Image Status (ogra, NCommander)
[14:28] <ogra> pretty much covered above already ...
[14:28] <NCommander> indeed
[14:28] <NCommander> [topic] AOB
[14:28] <MootBot> New Topic:  AOB
[14:28] <ogra> we need functioning kernels
[14:29]  * ogra has an AOB topic :)
[14:29] <ogra> davidm, what do we do with the mailing list now that we're being renamed
[14:29] <ogra> and also with #ubuntu-mobile
[14:30] <NCommander> Well, with #ubuntu-mobile, I thinkw e can let it die, we use #ubuntu-arm mostly now
[14:30] <ogra> shuld #ubuntu-mobile become a redirect to #ubuntu-arm or do we leave it idling
[14:30] <ogra> NCommander, define "let it die" :)
[14:30] <NCommander> let it idle
[14:30] <ogra> just leaving it wont magically make it go away
[14:31] <davidm> ogra, I need to talk with IS about the mailing list
[14:31] <ogra> its a registered ubuntu channel
[14:31] <davidm> ogra, I'd leave #ubuntu-mobile idle I think
[14:31] <ogra> hmm, k
[14:31] <davidm>  there is value to it, just not for us right now
[14:32] <ogra> indeed, but someone needs to be the owner (and make sure to be able to OP when spamboats or trolls show up)
[14:32] <davidm> hmm, I did not realize it was a registered channel, is #ubuntu-arm registered?
[14:32] <ogra> i think it is
[14:32] <ogra> has a chanserv
[14:32] <davidm> We should likely make sure
[14:32] <ogra> yeah
[14:35] <ogra> i think persia cared for -arm back when we got it new
[14:35] <ogra> NCommander, action for me to talk to persia about IRC channels
[14:35] <NCommander> [action] ogra to talk to persi about IRC channels
[14:35] <MootBot> ACTION received:  ogra to talk to persi about IRC channels
[14:35] <NCommander> Can I close out the meeting?
[14:35] <ogra> yeah
[14:35] <NCommander> #endmeeting
[14:35] <MootBot> Meeting finished at 08:35.
[14:36] <davidm> NCommander, you might take a tad more time to let folks respond to closing the meeting
[14:36] <NCommander> davidm: did you want to say something? (I can open it again)
[14:37] <davidm> I used the going 1 - 3 before closing to allow any last minute things
[14:37] <davidm> NCommander, no not worth opening again
[14:37] <NCommander> sorry about it
[14:37] <davidm> makes a new log
[14:37] <davidm> No worries
[14:57] <kees> \o
[14:57] <mdz> o/
[14:59] <pitti> \o
[15:01] <Keybuk> o|_|/
[15:01] <sabdfl> hello all
[15:01] <mdz> cjwatson: ping
[15:02] <cjwatson> hi, was just finishing up on the phone with lool
[15:02] <cjwatson> and that's everyone
[15:02] <cjwatson> Keybuk: relaxing then?
[15:02] <cjwatson> #startmeeting
[15:02] <MootBot> Meeting started at 09:02. The chair is cjwatson.
[15:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:02] <cjwatson> [TOPIC] Action review
[15:02] <MootBot> New Topic:  Action review
[15:02] <cjwatson> I don't see anything in the minutes from the last meeting that requires review
[15:02] <cjwatson> oh, wait
[15:02] <pitti> FTR, I'm in a parallel mumble OEM meeting, so I'm lagging a bit
[15:03] <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 process
[15:03] <cjwatson> mdz: did you raise that as resolved?
[15:03] <mdz> cjwatson: I've passed it on to marjo for the next stakeholder meeting
[15:03] <cjwatson> ok, thanks
[15:04] <cjwatson> [TOPIC] Review StableReleaseUpdates policy of contacting the Technical Board regarding regressions (mdz)
[15:04] <MootBot> New Topic:  Review StableReleaseUpdates policy of contacting the Technical Board regarding regressions (mdz)
[15:04] <cjwatson> mdz: go ahead
[15:04] <mdz> so, we've had a couple of regressions discovered in -proposed recently
[15:04] <mdz> and the wiki page tells people to email the tech board
[15:05] <mdz> this doesn't seem like the most helpful point of contact
[15:05] <mdz> so I would like to suggest that we direct these reports elsewhere
[15:05] <kees> seems like maybe "If you can't reach anyone else who will take responsibility, then email TB..."
[15:05] <pitti> right, I usually mark them as regression-proposed/verification-failed to prevent it being copied to -updates
[15:05] <mdz> for example to the QA team, or the SRU team, or someone like that
[15:05] <pitti> regressions in -updates are a different story, of course, and we should rather tell more people than fewer
[15:05] <cjwatson> there's also a rather out-of-date list of individuals in there somewhere
[15:06] <cjwatson> so, wait
[15:06] <cjwatson> I think this is actually bad wording on the page
[15:06] <mdz> pitti: yes, I think the page actually only says to email the TB regarding regressions in -updates
[15:06] <cjwatson> mdz: you're looking at the bit under "Procedure", right?
[15:06] <mdz> but people get confused
[15:07] <cjwatson> I'll take an action to reword that so that it explicitly applies to -updates
[15:07] <mdz> and I don't think the TB is ideal in that case either
[15:07] <cjwatson> [ACTION] cjwatson to reword StableReleaseUpdates to indicate that panic button only applies to -updates
[15:07] <MootBot> ACTION received:  cjwatson to reword StableReleaseUpdates to indicate that panic button only applies to -updates
[15:07] <cjwatson> (pending other discussion - that much is obviously sane, though)
[15:07] <mdz> agreed
[15:08] <mdz> does anyone else feel that the panic button could be improved as well?
[15:08] <cjwatson> I share some of that feeling, just thinking
[15:08] <cjwatson> the point of the panic button is to quickly escalate to people who can be effective
[15:08] <cjwatson> in doing things like reverting the update if appropriate, getting IS to block it if appropriate, etc.
[15:09] <mdz> I 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 approach
[15:09] <cjwatson> I 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 fuss
[15:09] <mdz> if we want is quick and accurate action, what we want to see is one person acknowledging and owning the problem and escalating it methodically
[15:10] <mdz> rather than potentially several people acting at once
[15:10] <cjwatson> we certainly want to end up with a single owner
[15:10] <mdz> IRC is pretty good for this
[15:10] <cjwatson> but it's valuable not to depend on a single person
[15:10] <mdz> because everyone else can see if someone has already responded
[15:10] <mdz> emailing the TB...not so much
[15:10] <cjwatson> which set of people is appropriate?  I would say either ~ubuntu-archive or ~ubuntu-sru
[15:11] <mdz> I think ~ubuntu-sru
[15:11] <cjwatson> probably the latter except that it's kind of small.  but maybe that's ok
[15:11] <cjwatson> we can delegate
[15:11] <cjwatson> do you think it's appropriate for IRC to be the only method?
[15:12] <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 admins
[15:12] <pitti> and telling IS to block updates is easier for Canonical folks with the emergency phone numbers
[15:14] <pitti> cjwatson: IRC seems fine to me; a lot of folks (slangasek, you, mdz, me) use proxies and are online 24/7
[15:14] <cjwatson> so should we have an explicit list of people, rather than a complicated set union/intersection?
[15:14] <cjwatson> and explain the rationale for that list, so that we can keep it up to date reasonably easily
[15:15] <mdz> ideally, a bot could handle this, and look up the team membership in LP
[15:15] <cjwatson> (which the current list hasn't been - AIUI Cody isn't the Xubuntu lead any more)
[15:15] <pitti> I liked the copy&paste "pitti, cjwatson, slangasek, ...: PANIC" quite a lot
[15:15] <mdz> so we keep it all in one place
[15:15] <cjwatson> (and Hobbsee hasn't been around much for a while)
[15:15] <pitti> it has few technical dependencies (bots, etc.)
[15:15] <cjwatson> mdz: we can probably do that, it's analogous to !ops
[15:15] <pitti> and is quick and easy to document and follow
[15:15] <cjwatson> we could have !sru
[15:16] <pitti> can this regularly sync team membership from LP without the need to look it up on the fly?
[15:16] <pitti> I wouldn't rely on the latter
[15:16] <cjwatson> seems technically possible :-)
[15:16] <cjwatson> agreed
[15:17] <mdz> that's all I had to say on the topic
[15:17] <mdz> the main point being dropping the "email technical-board@" step, since I don't think it adds value
[15:17] <mdz> there's nothing on there about creating an incident report either, and perhaps there should be
[15:19] <mdz> cjwatson: 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] <cjwatson> is somebody interested in taking an action to get the bot changes made?
[15:19] <cjwatson> otherwise it'll devolve to me I guess
[15:19] <cjwatson> the code appears to be in lp:ubuntu-bots
[15:20] <pitti> ah, I think I can try spending some time on that
[15:20] <mdz> that bit is less important, maybe we could just ask for help?
[15:20] <mdz> it's a bite-sized project someone could step up and do; it doesn't have to be one of us
[15:20] <cjwatson> I'd rather we get it done and close out the topic
[15:20] <mdz> fair enough
[15:20] <lool> (hi, joining)
[15:21] <cjwatson> [ACTION] pitti to (ask for help to) get !sru added to ubuntu-bots
[15:21] <MootBot> ACTION received:  pitti to (ask for help to) get !sru added to ubuntu-bots
[15:21] <cjwatson> [ACTION] cjwatson to remove "mail TB" step from SRU docs
[15:21] <MootBot> ACTION received:  cjwatson to remove "mail TB" step from SRU docs
[15:22] <mdz> move on?
[15:22] <cjwatson> yep
[15:22] <cjwatson> doko__: are you here?
[15:22] <doko__> yes
[15:22] <Keybuk> doko: do you have any sheep?
[15:23] <doko> Keybuk: just a robber for you
[15:24] <cjwatson> [TOPIC] Selection of the Linaro GCC for other architectures (doko)
[15:24] <MootBot> New Topic:  Selection of the Linaro GCC for other architectures (doko)
[15:24] <doko> cjwatson: how should we proceed? https://wiki.ubuntu.com/TechnicalBoardAgenda has the input about the Linaro GCC and the main question
[15:24] <cjwatson> so doko brought some concerns about this up over the weekend, and was kind enough to write it up for the agenda
[15:24] <cjwatson> the question for the TB is what we should be doing regarding the default Ubuntu toolchain
[15:24] <cjwatson> actually, I think this is doko's decision as maintainer, but he'd like advice
[15:25] <lool> I 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 developments
[15:25] <mdz> I don't have context on this; did I miss something on the mailing list?
[15:25] <lool> *ones
[15:26] <Keybuk> does the CodeSourcery GCC offer advantages for non-ARM platforms?
[15:26] <cjwatson> mdz: afraid not, this came up over the last couple of days and hasn't hit the list
[15:26] <lool> mdz: 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 late
[15:26] <lool> I think the UDS session called for testing on x86 and arm, and was reserved about usage on other arches
[15:27] <kees> if the linaro patchset is only applied to the armel build of gcc, it seems like that minimizes the potential "alienation".
[15:27] <doko> the CS changes include some middle-end changes and changes to backends. the ones we may be interested in are the intel archs and powerpc
[15:27] <cjwatson> kees: 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 other
[15:28] <cjwatson> there are risks with every option though :-)
[15:28] <doko> I do not want to touch archs which are not actively supported in the CS GCC
[15:28] <lool> Yes; 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 Ubuntu
[15:28] <kees> cjwatson: right, it just seems like that one contains the risk a bit more.  doing archive rebuilds is very expensive.
[15:29] <sabdfl> us using the CS patches for all arch's would help accelerate their upstreaming
[15:29] <cjwatson> lool: 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 too
[15:29] <lool> cjwatson: Linaro also forwards patches upstream though
[15:29] <sabdfl> and 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 issues
[15:29] <doko> the non-technical question I see is, how is Ubuntu seen if it uses a toolchain not directly from upstream
[15:30] <lool> cjwatson: it's our mission to upstream this stuff too, so we could in the end help upstreaming
[15:30] <cjwatson> my 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 ARM
[15:30] <cjwatson> I realise that they and Linaro have offered support otherwise
[15:30] <cjwatson> but I can't see how it can be top priority if there's a crunch
[15:30] <sabdfl> doko: 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 one
[15:30] <kiko> cjwatson, possibly -- but they do maintain the x86 side of the toolchain as well, just to be clear
[15:30] <cjwatson> kiko: not exclusively
[15:30] <cjwatson> they certainly help to do so
[15:30] <lool> doko: 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] <doko> cjwatson: not exactly, having an "interest" and providing support is different
[15:30] <kiko> cjwatson, no, I mean that they have x86 customers
[15:31] <lool> sabdfl: we provide gcc-snapshot though
[15:31] <kiko> so they do maintain it as well
[15:31] <cjwatson> FAOD I am not questioning either CS's skills or good faith
[15:31] <lool> it 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] <sabdfl> lool: right, so it's always possible to test if the CS work is the root cause of an issue
[15:31] <doko> lool: yes, we'll have a GCC version which is close to the upstream branches
[15:31] <lool> doko: Do you currently test with a vanilla toolchain before reporting upstream?
[15:31] <cjwatson> sabdfl: that's time-consuming work in an already time-consuming process, of course
[15:32] <cjwatson> I wonder if we should take a slightly different approach
[15:32] <sabdfl> we face this same story on kernel and elsewhere, anywhere we deviate from pristine upstream
[15:32] <sabdfl> cjwatson: yes, i understand that
[15:32] <lool> Yes, albeit the difference is substantial
[15:32] <cjwatson> package both the FSF gcc and the CS branch as separate packages
[15:32] <cjwatson> then, if there's a problem with one, a package can build-depend on and compile with the other
[15:32] <sabdfl> how expensive are rebuilds?
[15:32] <cjwatson> assuming that ABIs haven't skewed too much
[15:32] <cjwatson> sabdfl: very!
[15:32] <doko> lool: yes, depends on the situation. currently testing with both debian and ubuntu and trunk before reporting bugs
[15:32] <cjwatson> at least in Ubuntu
[15:32] <mdz> cjwatson: I guess I took that as a given
[15:33] <lool> cjwatson: Yes, just like gcc-4.5/gcc-4.4, gcc-linaro-4.4/4.5
[15:33] <mdz> that if we are going to use two different toolchains, we would package them separately
[15:33] <cjwatson> mdz: it wasn't doko's original proposition, but I'm interested how he feels about it
[15:33] <doko> cjwatson: well, there's still the problem of overlapping packages (runtime libs)
[15:33] <cjwatson> sabdfl: full rebuilds in Ubuntu are significant mirror-losing events
[15:33] <cjwatson> doko: mm, the runtimes concern me less really although I can see why we might want to think about them ...
[15:33] <lool> mdz: the options so far was to apply a Linaro patch in the gcc-4.4 build
[15:33] <sabdfl> cjwatson: sorry, i meant private rebuilds not hammering-the-archive
[15:33] <lool> there were other options, but basically resulting in the same
[15:34] <lool> (e.g. have gcc-4.4 on some arches, and gcc-linaro-4.4 on others)
[15:34] <cjwatson> sabdfl: oh, well, they monopolise PPA builders for the best part of a week IIRC
[15:34] <lool> doko: 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 bugs
[15:34] <sabdfl> if it's a question of more builders, that's relatively cheap
[15:34] <cjwatson> and for Linaro we're designing for them, although I imagine we still don't want to do that too often
[15:34] <cjwatson> or more often than necessary
[15:35] <sabdfl> doko: when you say trunk, you mean tip?
[15:35] <mdz> lool: I would prefer that we package both, and let both build on both architectures, to make it easier to isolate bugs
[15:35] <doko> sabdfl: yes
[15:35] <cjwatson> doko: how tight is the binding between g++-4.4 and libstdc++6-4.4-dev
[15:35] <cjwatson> ?
[15:35] <cjwatson> mdz: doko's right though, got to pick one or the other to win libgcc1
[15:35] <lool> mdz: It's possible albeit expensive, for buildd time and for the maintenance of the forked debian/
[15:35] <cjwatson> and libstdc++6
[15:35] <doko> cjwatson: it should be merged
[15:35] <cjwatson> doko: I'm not sure what that means
[15:35] <lool> mdz: but I see the value in your point
[15:35] <mdz> cjwatson, doko: are the runtime libraries significantly different?
[15:36] <kiko> sabdfl, 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 change
[15:36] <lool> Sufficiently that we need to include the CS patchset in gcc-4.5
[15:36] <mdz> lool: why buildd time? the toolchain doesn't change that much
[15:36] <doko> mdz: the only concern is libstdc++6, but we already have this problem with the 4.4/4.5 overlap
[15:36] <mdz> (that often, rather)
[15:36] <kiko> sabdfl, cjwatson: so while we should be careful to consider things now, we could postpone making a decision until we do have a rebuild as evidence
[15:36] <lool> mdz: No, but the time to deploy a fix across all toolchains is longer; toolchain build time is very long, on armel notably
[15:36] <sabdfl> kiko: we could ack CS patches subject to "no disasters in the rebuild review"
[15:36] <kiko> sabdfl, right
[15:36] <lool> doko: The runtime opts are also very important
[15:36] <cjwatson> I'd like us to explore doko's question of the community impact of using the CS patches as well, when we're ready
[15:37] <mdz> lool: fair point
[15:37] <doko> kiko: yes, we only have test packages since the weekend
[15:37] <kiko> doko, great job getting them ready! :)
[15:37] <mdz> we need to look at this as an ongoing concern, not a one-time decision
[15:37] <cjwatson> I 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 else
[15:37] <cjwatson> and I don't agree that that's an ipso facto unreasonable thing to do
[15:37] <lool> kiko: I would be careful not deferring too much, as noted earlier, as toolchain should get early in maverick
[15:38] <kiko> lool, I know, but a test rebuild is the minimal due diligence, do you not agree?
[15:38] <mdz> having a current CS toolchain in the archive at all times seems like a win
[15:38] <mdz> that's something of value beyond just building our packages
[15:38] <lool> kiko: I tend to think we should have one for x86 but can't afford to wait for an armel one
[15:38] <doko> we could have as well a decision for this cycle only (gcc-4.4) and revisit the question for mav+1 and gcc-4.5
[15:39] <lool> This is compensated by the battery of test which Linaro does before releasing (which is CodeSourcery's)
[15:39] <sabdfl> doko: +1
[15:39] <kiko> lool, I'm not thinking of an armel rebuild! just x86
[15:39] <cjwatson> so 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 toolchain
[15:39] <lool> doko: 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 though
[15:39] <sabdfl> cjwatson: there's no version change, which is the primary question
[15:39] <cjwatson> at least for architectures other than armel, which I agree is special in many ways
[15:39] <mdz> cjwatson++
[15:40] <cjwatson> sabdfl: I think the version is misleading
[15:40] <lool> kiko: We can take a decision including the outcome of the rebuild
[15:40] <doko> lool: the armel decision is independent from that one; I'd like to wait until I get feedback from CS about the merged packages first
[15:41] <lool> doko: (I'm not exactly sure which issue you relate to)
[15:41] <cjwatson> switching 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 change
[15:41] <doko> lool: having the CS patchset applied for armel
[15:41] <kiko> cjwatson, 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 accountable
[15:41] <sabdfl> another way to look at it is that having the CS folks focused on our toolchain broadens the eyeballs we have on GCC substantially
[15:41] <lool> cjwatson: Yes, it's a large change, smaller than 4.4 -> 4.5, but still a large change necessiting a rebuild
[15:42] <sabdfl> they are very good, by all accounts
[15:42] <kiko> or, 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 them
[15:42] <lool> doko: Sorry, I got confused in the discussion and don't understand the point  :-(
[15:42] <sabdfl> it smooths the way for their work to get upstream mainline too
[15:42] <cjwatson> as I said, I raise no question regarding the CS folks' skills or good faith
[15:42] <mdz> can we agree to rule out changing the x86 toolchain such that a rebuild is required in maverick?
[15:42] <sabdfl> we're still quite early in the cycle
[15:42] <cjwatson> sabdfl: (does it really?  CS already has folks on the GCC steering committee, I'm not sure how much another customer in fact helps)
[15:43] <lool> kiko: 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 achieve
[15:43] <sabdfl> not many customers are as high profile or build as much
[15:43] <doko> mdz: I can't think of changes that absolutely would require a rebuild
[15:43] <mdz> doko: lool just said that this would necessitate a rebuild
[15:43] <kiko> lool, no, he'll do it as part of the agreement to use his toolchain as default for us.
[15:43] <cjwatson> mdz: test rebuild
[15:43] <mdz> doko: the CS patches, that is
[15:43] <lool> mdz: it is a good idea to do a test rebuild
[15:43] <lool> mdz: not to rebuild the Ubuntu archives
[15:43] <kiko> lool, well, that's how I've presented it, anyway
[15:43] <lool> mdz: that is, I would rather do a test rebuild before uploading such a makor change
[15:43] <cjwatson> kiko: what will happen if there is a time conflict between Linaro/ARM work and Ubuntu/(say)x86 work?
[15:43] <lool> *major
[15:43] <cjwatson> which will win?
[15:44] <mdz> lool: oh, that's something different then
[15:44] <doko> mdz: right, it requires a test rebuild outside the archive, before the changed GCC is a candidate for upload
[15:44] <lool> mdz: No rebuild is needed, the ABI is compatible, and upwards
[15:44] <mdz> doko: yes, naturally
[15:44] <lool> It's a different story if we need to roll it out, that might be worth covering
[15:44] <kiko> cjwatson, we'll make sure CS fixes the critical bugs
[15: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:44] <mdz> doko: but what about testing that those rebuilt packages actually work?
[15:44] <kiko> cjwatson, I'm saying this because I know that they care about the state of their toolchain across architectures
[15:44] <kiko> cjwatson, and they will appreciate the additional testing
[15:45] <doko> kiko: yes, I may be overcautious, but there may be gap if Linaro/CS runs out of time
[15:45] <kiko> doko, we'll make it work
[15:45] <cjwatson> kiko: 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 architecture
[15:45] <cjwatson> and that essentially it was just the standard test suite
[15:45] <kiko> cjwatson, all the more reason for them to pay attention to problems we find
[15:45] <lool> it'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 around
[15:45] <cjwatson> agreed, but nevertheless it gives me concerns regarding a late deployment of the toolchain on Ubuntu x86
[15:45] <mdz> the more I hear, the more strongly I feel that the toolchains for x86 and ARM should be decoupled
[15:45] <doko> mdz: yes, we could do a test CD rebuild from the rebuilt packages
[15:45] <cjwatson> and I have to stress that, this is late
[15:45] <kiko> cjwatson, 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 speculation
[15:46] <cjwatson> certainly, and I think this will be an easier discussion for maverick+1 anyway
[15:46] <lool> I think we could take a decision depending on how good the rebuilds are
[15:46] <cjwatson> (not that I'm saying we should defer the whole discussion to then)
[15:47] <cjwatson> mdz: for maverick, my leanings are also in that direction, at the moment
[15:47] <cjwatson> I agree that a test rebuild will be useful information
[15:47] <kiko> I 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 is
[15:48] <kiko> how long will it take to run a rebuild, doko? is it running already?
[15:48] <mdz> kiko: my gut feel is "less painful than the tug-of-war between x86 and ARM"
[15:48] <doko> I think a test rebuild for main should be doable until the next TB meeting (not sure about ARM)
[15:48] <lool> kiko: Note that the pain is present in any case because I understand some Ubuntu arches will not use the Linaro patches
[15:48] <lool> and in any case doko would like to keep the option open of moving out of hte patches
[15:48] <lool> (finally Debian and Ubuntu patches are very similar and doko is maintaining the Debian patches, but that's another story)
[15:49] <kiko> doko, I really only care about an x86 rebuild
[15:49] <doko> kiko: will start this as soon as I get some feedback of some regressions in the GCC testsuite, which were seen after applying the patchset
[15:49] <mdz> kiko: why?
[15:49] <kiko> mdz, because it is the fastest way to obtain more information
[15:50] <kiko> and I hate deciding without adequate information  :-)
[15:50] <doko> I worked through all Ubuntu patches today with CS, they are mostly complementary
[15:50] <kiko> doko, have they replied to you yet?
[15:50] <kiko> oh, that s great to hear
[15:50] <doko> kiko: had a 5h phone call today
[15:51] <mdz> kiko: 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] <cjwatson> doko: complementary> as in, no serious conflicts?
[15:51] <kiko> mdz, 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] <mdz> kiko: a rebuild will not tell us what this decision will mean for the next four months
[15:51] <doko> we should be able to start a test rebuild later this week.
[15:51] <lool> mdz: 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/sparc
[15:52] <mdz> kiko: as I understand this discussion, forking the toolchain is inevitable. it's just a question of how we manage the fork.
[15:52] <doko> cjwatson: yes, and many arm patches we applied for karmic and lucid not in the CS changes
[15:52] <kiko> mdz, to me that wasn't clearly decided -- and I'd rather we didn't decide until we had more information
[15:53] <mdz> kiko: if you were happy with the current toolchain, we wouldn't be here right now :-)
[15:53] <kiko> but if we can't wait for a week then I guess your option is definitely the safest
[15:53] <mdz> I am not opposed to waiting a week
[15:53] <cjwatson> a week will put the toolchain change after alpha-2
[15:53] <cjwatson> (in practice)
[15:53] <mdz> but I also don't expect the result of a rebuild to have any significant impact on this decision
[15:54] <kiko> even in the edge cases of zero failures or millions of failures? ;-)
[15:54] <mdz> some things will build correctly, some will fail to build, and others will build but may not work
[15:54] <lool> doko: 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:55] <lool> doko: I wonder if it's expensive for us to rollback to the FSF toolchain if we chose the Linaro one on x86
[15:55] <mdz> kiko: I don't like the idea of pushing CS on x86 even if everything happens to build OK
[15:55] <kees> me either
[15:55] <mdz> this is a decision we have to live with; we can't base it only on what happens today
[15:55] <mdz> (even if we could test it more thoroughly)
[15:55] <doko> lool: currently I don't see why we would need to do so
[15:56] <lool> Ok, so it seems we would be taking a moderate risk if we need to roolback the toolchain, that's good to know
[15:56] <cjwatson> we have only a few minutes left, and we seem to have settled into fixed positions
[15:56] <doko> it's a bit more expensive to backout gcc-4.5
[15:56] <cjwatson> doko: do you think you have what you need here, or is there anything else you want to specifically discuss?
[15:58] <sabdfl> x86 CS is not a high risk
[15:58] <doko> cjwatson: 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 decision
[15:58] <sabdfl> the risks appear to be with sparc or ia64
[15:58] <sabdfl> which are being deprecated
[15:58] <mdz> sabdfl: you sound pretty confident in that
[15:58] <sabdfl> based on comments here, yes
[15:58] <doko> which we *hope* are being deprecated ;)
[15:58] <lool> sabdfl: 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 basis
[15:59] <lool> (I'm commenting on ia64/sparc)
[15:59] <cjwatson> my 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, TBH
[16:00] <doko> cjwatson: well, it should not introduce package build failures which need sourceful uploads, as 4.5 would require
[16:00] <mdz> and the benefit would be negligible
[16:01] <cjwatson> I'm going to have to cut us off here due to time.  I suggest that further discussion move to #ubuntu-devel or ubuntu-devel@lists
[16:01] <doko> mdz: well, the benefit would be better code generation even on ix86. I'll follow up on ubuntu-devel
[16:02] <cjwatson> there is one article on the mailing list which probably needs attention by somebody, namely https://lists.ubuntu.com/archives/technical-board/2010-June/000281.html
[16:02] <mdz> I also noticed in checking the mailing list that it is flooded with spam
[16:02] <cjwatson> but we probably don't have time to look into it now, if anybody has a moment please follow it up
[16:02] <cjwatson> [ACTION] cjwatson to find out about spam-cleaning technical-board@ archives with IS
[16:02] <MootBot> ACTION received:  cjwatson to find out about spam-cleaning technical-board@ archives with IS
[16:02] <mdz> the bug in that message is bug 586497
[16:02] <cjwatson> I haven't been seeing the same spam by mail but I suppose spamassassin could be filtering it here
[16:02] <cjwatson> [TOPIC] Check up on community bugs (standing item)
[16:02] <MootBot> New Topic:  Check up on community bugs (standing item)
[16:03] <cjwatson> just the ubuntu-drivers bug discussed earlier
[16:03] <cjwatson> [TOPIC] Select a chair for the next meeting
[16:03] <MootBot> New Topic:  Select a chair for the next meeting
[16:03] <kees> I think I'm up next to chair, is that right?
[16:03] <cjwatson> I make it kees
[16:03] <kees> done and done.
[16:03] <cjwatson> #endmeeting
[16:03] <MootBot> Meeting finished at 10:03.
[16:03] <mdz> thanks cjwatson
[16:03] <cjwatson> sorry for the slight overrun, all
[16:03] <kees> thanks!
[16:03] <pitti> thanks everyone
[16:03] <sabdfl> cheers all
[17:58] <JFo> o/
[17:58] <mpoirier> mpoirier \o
[17:58]  * apw bounces in
[17:58] <cnd> /\o/\
[17:58]  * cnd turned into a spider
[17:58]  * smb is there
[17:58]  * apw stamps on cnd
[17:58] <kamal> o/
[17:58] <JFo> I thought you were doing dips cnd :)
[17:59] <bjf> #startmeeting
[17:59] <MootBot> Meeting started at 11:59. The chair is bjf.
[17:59] <jjohansen> \o
[17:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:59] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:59] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[17:59] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:59] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[17:59] <bjf> #
[17:59] <bjf> # NOTE: '..' indicates that you are finished with your input.
[17:59] <bjf> #
[18:00] <bjf> [TOPIC] Release Metrics: (JFo)
[18:00] <MootBot> New Topic:  Release Metrics: (JFo)
[18:00]  * cking here
[18:00] <JFo> Bugs (Release Meeting Bugs / RC Milestoned Bugs / Release Targeted Bugs)
[18:00] <JFo> Release Meeting Bugs (1 bugs, 9 Blueprints)
[18:00] <JFo> [18:00] <JFo>  * 10 linux kernel bugs (up 9)
[18:00] <JFo> [18:00] <JFo>  * 17 linux kernel bugs (up 14)
[18:00] <JFo> [18:00] <JFo>  * 13 blueprints
[18:00] <JFo> *** NOTE: This listing includes HWE Blueprints***
[18:00] <JFo> [18:00] <JFo>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
[18:00] <JFo>  * Breakdown by status:
[18:00] <JFo>    http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/
[18:00] <JFo> ..
[18:01] <bjf> [TOPIC] Blueprint: kernel-maverick-apparmor (jjohansen)
[18:01] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
[18:01] <MootBot> New Topic:  Blueprint: kernel-maverick-apparmor (jjohansen)
[18:01] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
[18:01] <jjohansen> slow progress - updated compatibility code, need to do testing and send out pull request when done
[18:01] <lag> Oh, I missed the hellos
[18:01] <jjohansen> ..
[18:02] <bjf> [TOPIC] Blueprint: kernel-maverick-firewire-stack (manjo)
[18:02] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack
[18:02] <MootBot> New Topic:  Blueprint: kernel-maverick-firewire-stack (manjo)
[18:02] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack
[18:02] <manjo> nothing to report
[18:02] <manjo> ..
[18:02] <bjf> [TOPIC] Blueprint: kernel-maverick-misc (apw)
[18:02] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc
[18:02] <MootBot> New Topic:  Blueprint: kernel-maverick-misc (apw)
[18:02] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc
[18:02] <apw> The 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] <apw> ..
[18:03] <cnd> does this lift a hold on lucid patches against mvl-dove?
[18:04] <bjf> i believe that eric was waiting on this, so it should be a lift
[18:04] <smb> I pulled the tree that eric gave cnd
[18:04] <cnd> smb, for the LSP 5.2.1?
[18:05] <smb> So the tree should be ok now but the upload is waiting
[18:05] <smb> Yes
[18:05] <bjf> did he send out a new one for review after I NAK'd the last one?
[18:05] <smb> bjf, I thought it was a revised one
[18:05] <bjf> ok, don't remember seeing it
[18:05] <cnd> if not, I can rebase and find any compile failures and send a fix
[18:05] <smb> bjf, But I must admit he was confusing me quite a bit with all the pull request
[18:05] <cnd> ..
[18:05] <smb> ..
[18:06] <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-lts
[18:06] <MootBot> New Topic:  Blueprint: kernel-maverick-new-kernel-on-lts (tgardner)
[18:06] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts
[18:06] <tgardner> The LTS backport kernel and meta packages at http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu are up to
[18:06] <tgardner> 2.6.35-3.4 (tracking the latest maverick kernel release). All appears well. In fact, its much better then
[18:06] <tgardner> the previous 2.6.35-rc2 based release which had some memory corrupter bugs.
[18:06] <tgardner> ..
[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-kernel
[18:06] <MootBot> New Topic:  Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)
[18:06] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel
[18:06] <jjohansen> pv-on-HVM drivers don't help us out :(
[18:06] <jjohansen> Karmic 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] <jjohansen> Lucid pv-ops is boot in 2 of 4 availability zones on last test
[18:06] <jjohansen> Maverick wasn't booting at all under 2.6.35.2, have tried it with the latest config changes made pulled forward from Lucid and haven't tried .3 yet
[18:06] <jjohansen> Current 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:07] <jjohansen> ..
[18:07] <bjf> [TOPIC] Blueprint: kernel-maverick-tracing-support (cnd)
[18:07] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-tracing-support
[18:07] <MootBot> New Topic:  Blueprint: kernel-maverick-tracing-support (cnd)
[18:07] <apw> jjohansen, wasn't there a third option?
[18:07] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-tracing-support
[18:08] <jjohansen> apw: yeah the third option was full xen
[18:08] <apw> ok a middle option :)  the drivers only ?
[18:08] <cnd> Patch 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] <jjohansen> right the drivers are the pv-ops-HVM
[18:08] <cnd> ..
[18:09] <jjohansen> ..
[18:09] <bjf> [TOPIC] Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara)
[18:09] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review
[18:09] <MootBot> New Topic:  Blueprint: kernel-maverick-ubuntu-delta-review (ogasawara)
[18:09] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review
[18:09] <ogasawara> I pushed 3 of our sauce patches upstream which just removed some
[18:09] <ogasawara> duplicate device id's.  I've also dropped 2 more sauce patches which
[18:09] <ogasawara> added MODULE_ALIAS for the Dell WMI module and the other which sent
[18:09] <ogasawara> events on data interface as well as master interface for the hostap
[18:09] <ogasawara> driver.
[18:09] <ogasawara> ..
[18:09] <bjf> [TOPIC] Blueprint: kernel-maverick-union-mounts (apw)
[18:09] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-union-mounts
[18:09] <MootBot> New Topic:  Blueprint: kernel-maverick-union-mounts (apw)
[18:09] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-union-mounts
[18:09] <tgardner> ogasawara, you got some pushback on one of those removals. what came of that?
[18:10] <apw> Waiting 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] <apw> ..
[18:10] <ogasawara> tgardner: hrm, I didn't see any reply.
[18:10] <ogasawara> tgardner: I'll have to look into it
[18:10] <tgardner> ogasawara, the one with duplicate IDs
[18:11] <ogasawara> tgardner: I'm not subscribed to the upstream list so I wonder if I wasn't CC'd on the reply?
[18:11] <tgardner> ogasawara, likely
[18:11] <tgardner> ..
[18:11] <apw> google is your friend
[18:11] <bjf> [TOPIC] Blueprint: kernel-maverick-bug-handling (jfo)
[18:11] <bjf> [LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling
[18:11] <MootBot> New Topic:  Blueprint: kernel-maverick-bug-handling (jfo)
[18:11] <MootBot> LINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling
[18:12] <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] <JFo> ..
[18:13] <manjo> JFo, are we having community bug days ?
[18:13] <JFo> that information is coming up manjo
[18:13] <JFo> ..
[18:14] <bjf> [TOPIC] Blueprint: kernel-maverick-upstart (apw)
[18:14] <bjf> [LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart
[18:14] <MootBot> New Topic:  Blueprint: kernel-maverick-upstart (apw)
[18:14] <MootBot> LINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-upstart
[18:14] <apw> Waiting on testing from Foundation from updates kernels.  Expecting preliminary feedback on Wednesday.
[18:14] <apw> ..
[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-automation
[18:14] <MootBot> New Topic:  Blueprint: kernel-maverick-bios-test-automation (cking)
[18:14] <MootBot> LINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bios-test-automation
[18:15] <cking> Added the following functionality to the firmware test suite:
[18:15] <cking>   Battery Test: Exercise CPU to drain quicker
[18:15] <cking>   Kernel Version checking
[18:15] <cking>   Include Blank Test Template
[18:15] <cking>   Re-organise klog scanning, added more intelligence
[18:15] <cking>   Logging: Add line numbering, test failure levels, summary of failures, improved automatic text formatting
[18:15] <cking>   Add --no-s3 --no-s4 options to ignore suspend/hibernate tests
[18:15] <cking>   Check for redundant _OSI(Linux)
[18:15] <cking>   HPET sanity check vendor ID
[18:15] <cking>   Syntax check SSDT tables
[18:15] <cking>   Virtualisation extention checks
[18:15] <cking>   Add in MCFG test
[18:15] <cking>   General bug fixing and code tidying
[18:15] <cking> ..
[18:15] <bjf> [TOPIC] Status: Maverick (ogasawara)
[18:15] <MootBot> New Topic:  Status: Maverick (ogasawara)
[18:16] <ogasawara> We've rebased to 2.6.35-rc3 which should be available as of
[18:16] <ogasawara> linux-2.6.35-3.4.  Please test.
[18:16] <ogasawara> Alpha 2 is Thurs July 1 (ie ~2weeks from today) so make sure you're on
[18:16] <ogasawara> track with any work items that need doing as we're currently above the
[18:16] <ogasawara> trend 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.html
[18:16] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-2.html
[18:16] <ogasawara> Also keep in mind that if you have any patches which you want to land
[18:16] <ogasawara> in the Alpha2 kernel, they need to be sent to the kernel-team ml and
[18:16] <ogasawara> have garnered the appropriate Ack's *before* Fri Jun 25.  I'll send an
[18:16] <ogasawara> email reminder this Friday.
[18:16] <ogasawara> ..
[18:17] <bjf> [TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)
[18:17] <MootBot> New Topic:  Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)
[18:17] <smb> Dapper:      2.6.15-55.84  (security)
[18:17] <smb> Hardy:       2.6.24-28.70  (security)
[18:17] <smb>              2.6.24-28.71  (waiting for approval)
[18:17] <smb> Jaunty:      2.6.28-19.61  (security)
[18:17] <smb> Karmic:      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] <smb> Lucid:       2.6.32-22.36  (security)
[18:18] <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] <smb> As we found out today there is resistance on the current changes in Karmic
[18:18] <smb> which only affect the build infrastructure. This needs to be resolved
[18:18] <smb> before the uploads will be accepted into proposed.
[18:18] <smb> ..
[18:18] <JFo> that list is getting huge
[18:18] <JFo> ..
[18:19] <bjf> [TOPIC] Incoming Bugs: Regressions (JFo)
[18:19] <MootBot> New Topic:  Incoming Bugs: Regressions (JFo)
[18:19] <JFo> Incoming Bugs
[18:19] <JFo> 23 Maverick Bugs (up 8)
[18:19] <JFo> 950 Lucid Bugs (up 4)
[18:19] <JFo> Current regression stats (broken down by release):
[18:19] <JFo> [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> [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> [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> [18:19] <JFo>   * 1 lucid bug (no change)
[18:19] <JFo>   * 1 karmic bug (no change)
[18:19] <JFo> please 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] <JFo> ..
[18:20] <bjf> [TOPIC] Incoming Bugs: Bug day report (JFo)
[18:20] <MootBot> New Topic:  Incoming Bugs: Bug day report (JFo)
[18:20] <JFo> I 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] <JFo> ut 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:21] <JFo> Are you all finding the half day Kernel team days on friday and monday useful?
[18:21] <JFo> rather still finding them useful
[18:22] <jjohansen> well I like it
[18:22] <JFo> ..glad to hear it jjohansen
[18:22] <JFo> I think it is better than taking up a whole day
[18:22] <apw> i'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, yet
[18:23] <JFo> I understand
[18:23] <cking> JFo, not yet been able to find time for this time around
[18:23] <JFo> I think i'd like for them to be set on the schedule so that everyone knows when they are and we are consistently having them
[18:23] <JFo> cking, I understand :)
[18:23] <tgardner> JFo, lets keep doing it in order to see of the idea gets traction.
[18:23] <JFo> tgardner, will do
[18:23] <tgardner> s/of/if/
[18:24] <JFo> ..
[18:24] <bjf> [TOPIC] Open Discussion or Questions: Anyone have anything?
[18:24] <MootBot> New Topic:  Open Discussion or Questions: Anyone have anything?
[18:24] <ogasawara> o/ (I've got 2 items)
[18:24] <bjf> ogasawara, go
[18:24] <ogasawara> https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-gpu-freeze-reports
[18:24] <ogasawara> There are 3 Alpha2 work items assigned to the canonical-kernel-team in
[18:24] <ogasawara> that blueprint.
[18:24] <phunge0> o/
[18:24] <ogasawara> sconklin, could I persuade you to own those 3 work items? It looked like
[18:24] <ogasawara> you and apw attended this UDS session but apw seems to have enough
[18:24] <ogasawara> Alpha2 work items on his plate.
[18:25] <sconklin> looking
[18:25] <ogasawara> while you're looking, the other item was https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-uefi-support
[18:25] <ogasawara> This also has an Alpha2 work item assigned to canonical-kernel-team,
[18:25] <ogasawara> "Investigate situation with Intel graphics drivers on EFI".
[18:25] <ogasawara> cking or tgardner, did either of you attend this UDS session?  Can I get
[18:25] <ogasawara> one of you to own this work item?
[18:25] <sconklin> ogasawara: sure, I can take those
[18:26] <cking> ogasawara, nope, it clashed with something else I had to attend
[18:26] <ogasawara> sconklin: thanks, much appreciated.
[18:26] <tgardner> ogasawara, I volunteer cking as he's already involved with EFI
[18:26] <sconklin> I'll edit the blueprint now
[18:26] <manjo> can we get some feed back on the firewire stack switch? I think its a matter of blacklisting old modules and whitelisting new ones
[18:26]  * cking will pick it up then 
[18:26] <ogasawara> cking: thanks
[18:26] <ogasawara> ..
[18:26] <bjf> phunge0, go
[18:26] <phunge0> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092
[18:27] <phunge0> Could 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] <phunge0> Please let me know if there's someone specific I should be talking to.
[18:27] <tgardner> phunge0, is this so critical that you can't wait 2 weeks for it to show up in due course?
[18:27] <smb> I believe last time they had a fix they reverted it due to hangs in xfs
[18:28] <bjf> phunge0, it looks like we are waiting to see what upstream wants to do about it
[18:28] <smb> But it was one of the things I wanted to investigate
[18:28] <phunge0> ok
[18:28] <kamal> o/
[18:28] <apw> phunge0, do we have a poninter to the outstanding conversation on that
[18:28] <phunge0> it's not critical, but my firm was hoping to migrate to lucid with the SRU
[18:28] <phunge0> http://lkml.org/lkml/2010/6/10/259
[18:28] <MootBot> LINK received:  http://lkml.org/lkml/2010/6/10/259
[18:28] <apw> to the 'new' fix?  make it easier for us to track when it hits maverick so we can test
[18:28] <apw> phunge0, thanks
[18:28] <phunge0> and this blocks us
[18:29] <apw> phunge0, us ?
[18:29] <phunge0> this is the patchset http://lkml.org/lkml/2010/6/10/175
[18:29] <phunge0> my firm, sorry
[18:29] <tgardner> phunge0, it remains to be seen if Jens fix is gonna do the trick
[18:29] <apw> phunge0, thats like 13 patches!
[18:30] <tgardner> apw, maybe we can get it via stable :)
[18:30] <apw> tgardner, fingers crossed :)
[18:30] <phunge0> yeah, this is linus indicating that it might be acceptable for 2.6.35
[18:30] <smb> We might but that will certainly take time
[18:30] <apw> cirtainly we should help test it in 35
[18:30] <phunge0> http://lkml.org/lkml/2010/6/10/285
[18:30] <MootBot> LINK received:  http://lkml.org/lkml/2010/6/10/285
[18:30] <apw> ..
[18:30] <phunge0> but he pushed back
[18:30] <tgardner> ..
[18:31] <bjf> manjo, you have the floor
[18:31] <manjo> blacklist 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] <manjo> I emailed ubuntu-devel and ubuntu-kernel
[18:31] <apw> 'this switch' ?
[18:31] <manjo> and I don't have any response yet
[18:32] <bjf> apw, <manjo> can we get some feed back on the firewire stack switch? I think its a matter of blacklisting old modules and whitelisting new ones
[18:32] <manjo> ie switch from old firewire stack to new stack
[18:32] <apw> so i'd recommend you ask on #ubuntu-devel about this as well
[18:32] <tgardner> manjo, did your email include a patch?
[18:32] <apw> there are some old hands there who can probabally help guide us as to the next step
[18:33] <manjo> tgardner, no, I thought we talked about this a while back and
[18:33] <manjo> foundations need to make that change ?
[18:33] <tgardner> manjo, we can do it as well. we have before
[18:33] <manjo> I am happy to send a patch
[18:33] <manjo> tgardner, to ubuntu-kernel ?
[18:33] <apw> manjo, do we have the alternate userspace stack available ?
[18:33] <tgardner> I want some test results too.
[18:33] <apw> (i thought there was one if you switched?)
[18:33] <manjo> yep we have both moduels built as of now
[18:34] <tgardner> manjo, yep, ubuntu-kernel list
[18:34] <apw> manjo, i meant the userspace integration, does it work with both ?
[18:34] <apw> s/both/either
[18:34] <tgardner> apw, thats what I meant by test results
[18:34] <manjo> apw, there was a bug for which the switch was tested
[18:34] <manjo> but I can send a patch with test info
[18:34] <tgardner> manjo, just put the results in the bug
[18:35] <apw> sounds good then ...
[18:35] <JFo> I think we need a gneral CFT on the new stack then
[18:35] <manjo> tgardner, will do
[18:35] <tgardner> JFo, good idea
[18:35]  * JFo notes this
[18:35] <manjo> bjf, can you action me
[18:35] <manjo> so that I have this info for the next meeting
[18:35] <manjo> for/before
[18:36] <JFo> bjf, action me as well for the sending of the CFT
[18:36] <bjf> [ACTION] manjo to send a patch with test info
[18:36] <MootBot> ACTION received:  manjo to send a patch with test info
[18:36] <JFo> manjo, 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 stack
[18:36] <MootBot> ACTION received:  jfo to put out a CFT on new firewire stack
[18:36] <JFo> thanks bjf
[18:36] <JFo> ..
[18:37] <bjf> kamal, go
[18:38] <kamal> sri
[18:38] <kamal> Regarding bug 553498
[18:38] <kamal> We 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] <kamal> I 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] <kamal> What is the procedure?
[18:38] <bjf> SRU
[18:38] <apw> kamal, propose it as an SRU patch in the normal way
[18:38] <apw> send it to the kernel-team list etc
[18:39] <apw> ..
[18:39] <tgardner> that one seems like a good stable update patch
[18:39] <kamal> ok, will do -- can I change the bug state from "Fix Committed" back to "In Progress" or something also?
[18:39] <smb> Would there be chance that GregKH accepts it into stable upstream?
[18:39] <tgardner> smb reads my mind
[18:40] <apw> cirtainly worth asking ...
[18:40] <bjf> kamal, you can also open a new bug just for the purposes of SRU, point back at the other bug
[18:40] <smb> kamal, as bjf suggest
[18:40] <kamal> bjf, ok I'll open a whole new bug for this -- should I ask GregKH about this directly?
[18:40] <smb> Sounds strange that the bug only closes dell but is named generically
[18:41] <kamal> the bug was originally titled "Dell Studio ..." but I changed it after realizing that it affected all (?) i3/i5/i7 machines
[18:41] <apw> kamal, yeah we should get the title of the dell only bug fixed to be dell only and make the new one generic
[18:41] <smb> kamal, I wonder whether I have not written some notes how to do
[18:41] <smb> kamal, let me dig and get back to you
[18:42] <kamal> apw: ok, that makes sense re: the bug titling.
[18:42] <kamal> smb: I'll wait for your notes.
[18:42] <kamal> thanks folks
[18:42] <kamal> ..
[18:42] <bjf> anyone else have anything?
[18:42] <manjo> ..
[18:42] <bjf> thanks everyone
[18:42] <bjf> #endmeeting
[18:42] <MootBot> Meeting finished at 12:42.
[18:42] <JFo> thanks bjf
[18:42] <apw> bjf thanks
[18:42] <manjo> thanks bjf
[18:43] <kamal> thanks bjf
[18:43] <smb> thanks bjf
[18:58] <SpamapS> ~\o
[18:58] <hggdh> ~o~
[18:58] <ttx> o/
[18:59] <mathiaz> &o/\
[18:59] <ttx> SpamapS, mathiaz: time for a Java discoveraibility discussion after the meeting&call ?
[18:59] <zul> gday (channeling my inner dingo)
[18:59] <mathiaz> SpamapS: sure
[18:59] <kirkland> o/
[18:59] <mathiaz> ttx: ^^
[18:59] <SpamapS> ttx: definitely
[18:59] <ttx> cool.
[19:00] <Daviey>  ^
[19:00] <Daviey> \o
[19:00] <jjohansen> o/
[19:00] <jiboumans> good aftermorniving
[19:00] <jiboumans> #startmeeting
[19:00] <MootBot> Meeting started at 13:00. The chair is jiboumans.
[19:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:01] <jiboumans> thanks all for joining, today's scribe will be Daviey
[19:01] <Daviey> \o
[19:01] <jiboumans> [TOPIC] Review ACTION points from last meeting
[19:01] <MootBot> New Topic:  Review ACTION points from last meeting
[19:01] <jiboumans> ttx to coordinate testing for Alpha 2
[19:01] <jiboumans> for those following along at home, the agenda is up at: https://wiki.ubuntu.com/ServerTeam/Meeting
[19:01] <ttx> when alpha2 is near.
[19:02] <ttx> carryover.
[19:02] <jiboumans> very well.
[19:02] <jiboumans> smoser to train someone on the release team on the cloud image release
[19:02] <smoser> o/
[19:02] <smoser> not done.
[19:02] <jiboumans> smoser: anything blocking you?
[19:03] <smoser> i will contact release team to make sure someone else is able.
[19:03] <jiboumans> alright, 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 it
[19:03] <jiboumans> smoser to provide a more detailed work item overview for server-maverick-cloud-kernel-upgrades
[19:03] <smoser> that is done.
[19:04] <jiboumans> smoser: ta
[19:04] <jiboumans> all to keep their specs uptodate with workitems and update their status monday EOB
[19:04] <jiboumans> seems we have nice status updates on our WI tracker, thanks all
[19:04] <jiboumans> http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-2.html for those following along
[19:04] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-2.html for those following along
[19:05] <jiboumans> leaving sommer's action point till his section as he'll be a bit late today
[19:05] <jiboumans> moving on:
[19:05] <jiboumans> [TOPIC] Maverick development (jib)
[19:05] <MootBot> New Topic:  Maverick development (jib)
[19:05] <jiboumans> we're half way through the development cycle to the Alpha2 milestone right now
[19:06] <jiboumans> most 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 support
[19:06] <jiboumans> some are well ahead of that curve so we should have some slack in that area
[19:06] <jiboumans> I now give you ttx to go throught he specifics:
[19:06] <jiboumans> [TOPIC] Alpha2 subcycle status (ttx)
[19:06] <MootBot> New Topic:  Alpha2 subcycle status (ttx)
[19:06] <mathiaz> jiboumans: I've added some WI as I've refined some of the work to be done
[19:07] <mathiaz> jiboumans: so the percentage completion may move around as I've recorded more accurately what needs to be done
[19:07] <jiboumans> mathiaz: 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 progress
[19:07] <ttx> oops
[19:07] <jiboumans> mathiaz: in all cases accuracy trumps number juggling :)
[19:07] <ttx> missed the last 5 minutes
[19:08] <jiboumans> ttx: sorry, you still have to do your bit
[19:08] <jiboumans> ttx: [TOPIC] Alpha2 subcycle status (ttx)
[19:08] <ttx> About alpha2 status ?
[19:08] <ttx> ok
[19:08] <ttx> We are going reasonably well
[19:09] <ttx> the UEC specs are slightly late but we've been addressing that
[19:09]  * hggdh blushes
[19:09] <ttx> jiboumans: want to do a quick oneliner on progress ?
[19:10] <jiboumans> ttx: i'd like to highlight the ones that we've just reviewed and rescoped somewhat
[19:10] <mathiaz> ttx: should the update section cover that?
[19:10] <jiboumans> which i believe is UEC testing, qa-workflow and cloud-init right?
[19:10] <mathiaz> ttx: I'll be experimenting with a new format/template for the status section of BP
[19:10] <mathiaz> ttx: you should see the output of this in the coming days
[19:10] <ttx> and cloud-utils and uecec2-kernel-updates
[19:11] <jiboumans> ttx: can you fill us in what happened on those specs?
[19:11] <ttx> mathiaz: good
[19:11] <ttx> sorry, my IRc client is acting funny
[19:11]  * mathiaz hands a bottle of wine to ttx 
[19:11] <ttx> UEC testing was rescoped to concentrate on fixing the current issues to get to a stable situation, and engage in training new people
[19:12] <ttx> qa workflow was moved to A3 to give priority to uec-testing
[19:12] <ttx> cloud-init was trimmed down to move prio-3 things as targets of opportunity
[19:12] <ttx> cloud-utils first work items were reassigned to clint
[19:13] <ttx> and uec-ec2-kernel-updates work items were clarified
[19:13] <ttx> I think we now have a stable and clear view on what's expected from everyone
[19:13] <ttx> if someone thinks he cannot make it, please raise the red flag !
[19:14]  * mathiaz raises a bottle of wine towards ttx 
[19:14] <jiboumans> thanks for that summary ttx
[19:14] <jiboumans> this segways nicely to:
[19:14] <jiboumans> [TOPIC] Feature Definition Freeze this week (ttx)
[19:14] <MootBot> New Topic:  Feature Definition Freeze this week (ttx)
[19:14] <ttx> Looking at http://people.canonical.com/~pitti/workitems/maverick/canonical-server-maverick-alpha-2.html gives you a clear commonly shared view on what's expected
[19:14] <ttx> Right, this Thursday is FDF*
[19:14] <ttx> we need to freeze the design on all specs that affect main packages
[19:14] <ttx> and present those to the release team
[19:15] <ttx> We should be in good shape there, with the A2+A3 planning we've done so far
[19:15] <mathiaz> ttx: do you have a list of WI that are impacted by FF?
[19:15] <mathiaz> ttx: is this what you're looking for?
[19:15] <ttx> mathiaz: no
[19:15] <mathiaz> ttx: or is it more at the BP level?
[19:15] <ttx> mathiaz: I ean, no, I'm not really needing that
[19:16] <ttx> I need to come up with a list of all specs that will land features in main
[19:16] <SpamapS> ttx: 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] <jiboumans> SpamapS: yes
[19:16] <jiboumans> clarity++
[19:16] <ttx> and the release team will look into them, so applying some polish to the spec docs can't hurt
[19:16] <ttx> yes, updating the spec wikidoc with current design is necessary
[19:17]  * SpamapS digs around under the kitchen sink and emerges with a bottle of windex
[19:17] <mathiaz> ttx: are MIR considered new features?
[19:17] <ttx> mathiaz: that's an ongoing debate.
[19:17] <ttx> I'd say in that context, yes.
[19:17] <ttx> They want to know what will be hitting them
[19:18] <jiboumans> i'd err on the side of caution here too and highlight these
[19:18] <mathiaz> ttx: ok - so what do you expect from the team members?
[19:18] <ttx> even if MIRteam != ReleaseTeam it still affects the contents of main.
[19:19] <ttx> take some time[tm] to review the specs and making sure they are current.
[19:19] <mathiaz> ttx: should I review all my specs and flags wether they're impacted by FF?
[19:19] <ttx> I'll take it from there.
[19:19] <mathiaz> ttx: ok
[19:19] <ttx> If I have any question, I'll ask them.
[19:19] <jiboumans> mathiaz, ttx: looking at the specs and work items, it looks fairly straightforward
[19:20] <ttx> jiboumans: ack, should be straightforward.
[19:20] <jiboumans> but to all, please be aware yourself which items affect FDF so you can answer any questions if need be
[19:21] <jiboumans> ttx: anything more on FDF?
[19:21] <ttx> no.
[19:21] <jiboumans> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:21] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:21] <ttx> Did anyone mention that Daviey was the scribe yet ?
[19:21] <jiboumans> ttx: first thing, yes
[19:21] <zul> ttx: off hand yes
[19:21] <hggdh> on my side
[19:21] <Daviey> ttx: Shh!
[19:21] <ttx> I missed tat as well :)
[19:22] <hggdh> rigth now testing the metadata issue fix, and preparing to get to Lexington next week
[19:22] <hggdh> no real other news right now (except that the fix does not absolutely good right now)
[19:22] <ttx>  does not absolutely good ?
[19:23] <ttx> as in, doesn't work ?
[19:23] <hggdh> ttx: sort of. I am still getting metadata failures
[19:23] <mathiaz> hggdh: what's the state of the lucid ubuntuX.2 SRU
[19:23] <mathiaz> hggdh: ?
[19:23] <mathiaz> hggdh: has the package been pushed from -proposed to -updates?
[19:24] <hggdh> mathiaz: this was tested last week, and marked verification-done. I think today they made it into -updates
[19:24] <mathiaz> hggdh: indeed - thanks for testing all the bugs
[19:25] <jiboumans> hggdh++ indeed
[19:25] <jiboumans> any questions for the QA team?
[19:25] <jiboumans> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:25] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:25] <jiboumans> thanks hggdh
[19:26] <jjohansen> well first off some updates
[19:26]  * sommer arrives
[19:26] <jjohansen> the pv-ops kernel for EC2 hasn't been working out so we are shelving it for at least alpha2 and will update the Xen patches
[19:26] <zul> boo!
[19:27] <jiboumans> sommer: good timing, you're up after this ;)
[19:27] <jjohansen> seems zul wants to volunteer to work on it
[19:27] <sommer> :-)
[19:27] <jjohansen> :)
[19:27] <zul> NO!
[19:27] <jjohansen> the kernel has some known performance regressions, that will probably be in alpha2
[19:27] <smoser> boo indeed.
[19:28] <jiboumans> jjohansen: as in, the alpha2 kernel will have these known regressions?
[19:28] <jjohansen> smoser: well part of that is so I have time to do testing of other amazon stuff
[19:28] <jjohansen> yes
[19:28] <jiboumans> jjohansen: then i assume targeted for alpha3 are the fixes to those regressions?
[19:29] <jiboumans> jjohansen: where can we read about these regressions btw?
[19:29] <jjohansen> hopefully, the problem is known upstream
[19:29] <jjohansen> and the fixes will be coming from upstream kernels in later a RC
[19:30] <jjohansen> the kernel team has would like to know some more about Bug #588861
[19:30] <Daviey> jjohansen: hey
[19:30] <jjohansen> hey Daviey
[19:30] <ttx> Daviey: what's the status of your investigations there ?
[19:31] <Daviey> Triaging 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 reprdouce
[19:31] <Daviey> So since, the latest kernel, we haven't had an enviroment where we can reproduce that
[19:31] <ttx> Daviey: if you have bug numbers for those foundations issues, they can be raised in the release team meeting
[19:32] <Daviey> Therefore, i've been unable to provide further information OR confirm if the issue is still ongoing in the latest kernel
[19:32] <jjohansen> Daviey: so we know its kernel related, and not an update to something else
[19:32] <ttx> as blocking us.
[19:32] <Daviey> ttx: That is what i'm spending all tommorrow attempting to triage
[19:32] <ttx> Daviey: ok, keep us posted if we need to escalate how blocking this is
[19:32] <jjohansen> Daviey: okay, the question came up as we were considering adding to the kernel teams top 50
[19:32] <Daviey> jjohansen: That bug is kernel related.. but due to other platform issues - it can't yet have an enviroment to attempt to triage/reproduce
[19:33] <ttx> Daviey: alpha1 was exhibiting the bug, right ?
[19:33] <jjohansen> Daviey: okay, keep me posted and I will recommend adding it to the top 50
[19:33] <Daviey> jjohansen: Yes
[19:33] <ttx> Daviey: so we could install alpha1 and reproduce it
[19:33] <Daviey> jjohansen: I'll update the bug and EOP tommorrow, with the current status
[19:33] <Daviey> ttx: yes
[19:33] <jjohansen> okay, thanks Daviey
[19:34] <Daviey> Hmm, alpha1 with current kernel might be an interesting experiment to see if it is fixed
[19:34] <Daviey> <-- /me will do that
[19:34] <ttx> Daviey: ping me if you need help -- I can spend some cycles on reproducing that
[19:34] <Daviey> ttx: super, more hands the better
[19:35] <ttx> jjohansen: any progress on the atop patchset ?
[19:35] <jjohansen> not yeet
[19:36] <jjohansen> s/yeet/yet/
[19:36] <ttx> jjohansen: ok
[19:36] <jjohansen> any other questions for the kernel team?
[19:36] <Daviey> jjohansen: nothing server related from me, thanks!
[19:36] <jiboumans> jjohansen: do you think we can get some cycles on the atop patch in the next week?
[19:36] <jiboumans> we 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 up
[19:36] <jjohansen> jiboumans: yes
[19:37] <jiboumans> jjohansen: thanks, let me action that
[19:37] <Daviey> Do we have some ACTION's here?
[19:37] <jiboumans> [ACTION] jjohansen to review atop patchset for Alpha3 planning purposes
[19:37] <MootBot> ACTION received:  jjohansen to review atop patchset for Alpha3 planning purposes
[19:37] <jjohansen> jiboumans: I'll see if I can't get you an answer on them by eob tomorrow
[19:37] <jiboumans> [ACTION] Daviey to update #588861, if needed against alpha1
[19:37] <MootBot> ACTION received:  Daviey to update #588861, if needed against alpha1
[19:38] <jiboumans> jjohansen: that'd be great, but this week is good already
[19:38] <jjohansen> okay
[19:38] <Daviey> awesome.
[19:38] <jiboumans> alright, thanks lads
[19:38] <jiboumans> [TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)
[19:38] <MootBot> New Topic:  Weekly Updates & Questions for the Documentation Team (sommer)
[19:39] <jiboumans> sommer: first question is of course what can we help you with ?
[19:39] <sommer> I added some items to the blueprint: https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-serverguide-updates
[19:39] <sommer> but I think the one I'll need the most help with is the UEC section
[19:40] <jiboumans> alright; daviey, kirkland, who of you would be up for taking that on?
[19:40]  * kirkland points at Daviey 
[19:40] <Daviey> Depending on the UEC blocking stuff, i could spare some.
[19:40] <sommer> for lucid I took the information from the wiki, so it would be great if someone could at least review what's  there
[19:40] <kirkland> sommer: Daviey there are a couple of good resources available for this already
[19:40] <ttx> sommer: deadline is ?
[19:41] <kirkland> Daviey: sommer: much has been written, just needs re-publication into the Server Guide format
[19:41] <sommer> ttx: september 9th
[19:41] <kirkland> sommer: you can start with http://help.ubuntu.com/community/UEC
[19:41] <Daviey> Currently UEC /doesn't work/ on Maverick.. I need to work on that first.. but after that i can spare some.
[19:41] <jiboumans> sommer: i'll edit the bp now, feel free to translate that to work items as appropriate
[19:41] <Daviey> Otherwise.. /me points at kirkland :)
[19:41] <kirkland> sommer: can you read through what we've written at that link above?
[19:41]  * ttx would advise having those items for the beta iteration
[19:41] <kirkland> sommer: come back to us in a week or so, and let us know what you need more directly?
[19:41] <kirkland> sommer: based on what you need, i bet daviey and i can help
[19:42] <Daviey> +1
[19:42]  * kirkland agrees with Daviey, UEC is busted in Maverick; that needs fixing first
[19:42] <sommer> kirkland: sure, I'd planned to, but only have two machines with the vt extensions
[19:42] <kirkland> sommer: you only need 1 to do UEC ;-)
[19:42] <Daviey> sommer: two is plenty! :)
[19:42] <jiboumans> sommer: i see a few more items you need assistance wtih
[19:42] <jiboumans> shall we add some names to that list?
[19:43] <sommer> jiboumans: that'd be great, I planned on pinging ivoks about the clustering sections
[19:43] <jiboumans> clustering sounds like RoAkSoAx / ivoks indeed
[19:43] <jiboumans> vmbuilder?
[19:43] <sommer> ttx gave me some updates for the Tomcat section a while back, but I can also test that
[19:44] <jiboumans> sommer: puppet(mathiaz) and tomcat (ttx) seem straight forward too
[19:44] <ttx> ufw -> jdstrand
[19:44] <sommer> I'll ping soren about the vmbuilder stuff
[19:44] <ttx> vmbuilder -~~> soren?
[19:44] <sommer> hopefully get ahold of him at some point :)
[19:44] <Daviey> sommer: Awesome, this is sounding like the best doc's yet!
[19:44] <jiboumans> that leaves install tasks & opennebula
[19:45] <ttx> I'd drop opennebula, it's not really in our core cloud strategy
[19:45] <sommer> is opennebula widely used?
[19:45] <sommer> ttx: sounds good to me
[19:45]  * ttx never used it
[19:45] <jiboumans> sommer: there's some people experimenting with it
[19:45] <ttx> I think it's still universe ?
[19:45] <jiboumans> sommer: i couldn't speak to the state of opennebula on ubuntu right nwo though
[19:45] <zul> no i dont think so...afaik it still in unvierse and didnt build afaik
[19:45]  * mathiaz agrees
[19:45] <SpamapS> what about documentation for pending MIR's ?
[19:45] <mathiaz> sommer: I'd drop opennebula for maverick
[19:46] <jiboumans> it's the same as in karmic
[19:46] <ttx> SpamapS: ?
[19:46] <sommer> mathiaz: sounds good will do
[19:46] <jiboumans> which is a minor patch on jaunty
[19:46] <SpamapS> ttx: I'm not clear on what needs to be in the docs.. everything in main that is server related?
[19:46] <jiboumans> ttx: are you ok with supporting sommer on documenting the new install tasks?
[19:46] <mathiaz> SpamapS: not necessarly (actually not at all)
[19:46] <ttx> jiboumans: sure
[19:47] <SpamapS> Ok, 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] <mathiaz> SpamapS: we've got to decide what is *worth* putting in the server guide
[19:47] <jiboumans> sommer: could you please double check that the spec reflects the new reality? https://blueprints.edge.launchpad.net/ubuntu/+spec/server-maverick-serverguide-updates/+whiteboard
[19:47] <sommer> SpamapS: historically the serverguide has included items that will help an admin new to ubuntu to get up and running quickly
[19:47] <sommer> jiboumans: sure
[19:48] <jiboumans> on that note: edge.launchpad.net++ for having wider whiteboards
[19:48]  * ttx hugs Bryce for unclutterring the whiteboard
[19:48] <SpamapS> ok so the monitoring framework stuff for alpha3 may need some docs (though the spec is stil "pending approval")
[19:48] <jiboumans> sommer: 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 iteration
[19:48]  * kirkland high fives bryce too
[19:48] <jiboumans> sommer: for the others, whenever is good for them of course
[19:49] <sommer> jiboumans: will do
[19:49] <jiboumans> SpamapS: that'll be true until just before Alpha3
[19:49] <jiboumans> we don't 'approve' them until we've commited to work on them
[19:49] <jiboumans> and we decide that on a per-iteration basis
[19:50]  * SpamapS continues absorbing the process
[19:50] <SpamapS> :)
[19:50] <jiboumans> sommer: anything else from you?
[19:50] <sommer> I think that's it... thanks everyone for your help :)
[19:51] <jiboumans> sommer++ no, thank you
[19:51] <jiboumans> [TOPIC] Papercuts Alpha2 subcycle status (ttx)
[19:51] <MootBot> New Topic:  Papercuts Alpha2 subcycle status (ttx)
[19:51] <ttx> quick status
[19:51] <ttx> https://launchpad.net/server-papercuts/+milestone/maverick-alpha-2
[19:51] <ttx> all assigned
[19:51] <ttx> 65% fixed
[19:51] <ttx> Remember to nominate for the next cycle
[19:51] <ttx> we have a shortage in nominations
[19:52] <ttx> done.
[19:52] <jiboumans> ttx++ thanks
[19:52]  * SpamapS has a couple in mind but cannot nominate for milestones.. yet
[19:52] <jiboumans> [TOPIC] Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)
[19:52] <MootBot> New Topic:  Weekly SRU review: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review (mathiaz)
[19:52] <jiboumans> SpamapS: tell ttx about 'm and he can nominate on yoru behalf
[19:52] <ttx> SpamapS: you can "nominate for papercuts"
[19:52] <mathiaz> zul: what's the state of the weekly nomination script?
[19:52] <SpamapS> ttx: right, right. :)
[19:52] <ttx> SpamapS: just mark as "Also affecting" server-papercuts
[19:53] <mathiaz> zul: the WI is marked as done - I haven't seen an email going out though
[19:53] <zul> so the weekly nomination stuff is a work in progress
[19:53] <mathiaz> one bug nominated for lucid: bug 588293
[19:54] <mathiaz> anything worth SRUing on http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html ?
[19:54] <mathiaz> ^^?
[19:54] <SpamapS> https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/419091  not on that list, but worth SRU'ing into karmic
[19:54] <zul> mathiaz: bug 572410
[19:55] <Daviey> possibly 579584
[19:55] <Daviey> bug 579584
[19:56] <ttx> SpamapS: karmic ?
[19:56] <SpamapS> ttx: it was fixed in lucid, but karmic cannot stop couchdb.
[19:56] <mathiaz> SpamapS: that's annoying
[19:56] <mathiaz> SpamapS: if the patch is really simple it may be worth SRUing
[19:56] <SpamapS> the init script was totally rewritten for lucid .. and would be a simple backport.
[19:57] <mathiaz> SpamapS: hm - I've approved the nomination for now
[19:57] <jiboumans> SpamapS: the only real answer is: http://www.youtube.com/watch?v=Fow7iUaKrq4 #light-hearted
[19:57] <jiboumans> any other nominations?
[19:57] <SpamapS> jiboumans: ++
[19:57] <jiboumans> [TOPIC] New SRU Tracker (zul)
[19:57] <MootBot> New Topic:  New SRU Tracker (zul)
[19:58] <zul> hi
[19:58] <zul> so for the maverick uds we are changing the way we do nominations for SRU...
[19:58] <mathiaz> Daviey: does the bug fit the SRU criteria?
[19:58] <jiboumans> [LINK] http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html
[19:58] <MootBot> LINK received:  http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html
[19:58] <zul> we are taking it to the ubuntu-server list to get more feedback, the email will be starting shortly after some introduction
[19:59] <Daviey> mathiaz: possibly, requires more investigation
[19:59] <zul> we are also monitoring the status of the SRU nominated bugs (work in progress) at http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html
[19:59] <jiboumans> zul++
[19:59] <zul> basically its a cron job that sucks in launchpad into a sql database and displays the results
[20:00] <zul> it runs nightly so the information might be out of date sometimes
[20:00] <mathiaz> zul: this is great work
[20:00] <ttx> The results are slightly false though
[20:00] <jiboumans> i'd like to integrate this in our SRU reviews as well
[20:00] <ttx> I hear you have a fix for the "all boxes are green" issue
[20:00] <zul> ttx: yeah because i havent worked out all the bugs yet
[20:00] <ttx> ack
[20:00] <jiboumans> it's work in progress, but even the early version is helpful imho
[20:01] <jiboumans> zul: moving it to an LP branch a la work-item-tracker's good i think
[20:01] <zul> in the second table on that page is a list of nominated bugs that no one has worked on
[20:01] <mathiaz> yes - we can already spot bugs that could handle some testing
[20:01] <zul> funny that you mention that https://code.edge.launchpad.net/~zulcss/+junk/server-sru-tracker
[20:01] <mathiaz> zul: of *accepted* bugs
[20:01] <jiboumans> zul: minues the +junk? :)
[20:01] <zul> but it has to be moved to its own project
[20:02] <zul> jiboumans: ack
[20:02] <jiboumans> zul: indeed
[20:02] <jiboumans> [ACTION] zul to move the sru tracker code to it's own project
[20:02] <MootBot> ACTION received:  zul to move the sru tracker code to it's own project
[20:02] <jiboumans> zul++ thanks for whipping this up
[20:02] <jiboumans> any more questions on the tracker?
[20:02] <ttx> yay, let's branch it
[20:02] <zul> ttx: and mock the code? :)
[20:02] <Daviey> fork that.
[20:02] <jiboumans> [TOPIC] Open Discussion
[20:02] <MootBot> New Topic:  Open Discussion
[20:03] <jiboumans> going once...
[20:03] <Daviey> None here.
[20:03] <jiboumans> going twice...
[20:03] <ttx> ...
[20:03] <jiboumans> sold to the bearded lady in the back
[20:03] <jiboumans> [TOPIC] Announce next meeting date and time
[20:03] <jiboumans> Tuesday 2010-06-22 at 1800 UTC - #ubuntu-meeting
[20:03] <MootBot> New Topic:  Announce next meeting date and time
[20:03] <jiboumans> #endmeeting
[20:03] <MootBot> Meeting finished at 14:03.
[20:03] <Daviey> o/
[20:03] <jiboumans> thanks all
[20:04] <sommer> party! :-)
[21:00] <czajkowski> Aloha folks
[21:00] <popey> o/
[21:00] <czajkowski> Meeting for loco council starting shortly
[21:00] <czajkowski> #startmeeting
[21:00] <MootBot> Meeting started at 15:00. The chair is czajkowski.
[21:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:00] <czajkowski> Aloha folks LoCo Council meeting on now
[21:00] <czajkowski> [link] https://wiki.ubuntu.com/LoCoCouncil/Agenda
[21:00] <MootBot> LINK received:  https://wiki.ubuntu.com/LoCoCouncil/Agenda
[21:01] <czajkowski> This evenings short agenda
[21:01] <huats> hello czajkowski !
[21:01] <itnet7> Hello everyone! :-)
[21:01] <czajkowski> [topic] Best Guide and Practices
[21:01] <MootBot> New Topic:  Best Guide and Practices
[21:02] <czajkowski> [link] https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamsBestPracticesandGuidelines
[21:02] <MootBot> LINK received:  https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamsBestPracticesandGuidelines
[21:02] <czajkowski> so just to make teams aware of a guide we've put together to help teams
[21:03] <czajkowski> The idea of this document is to help new teams set up and do some regular things that we have found work for teams
[21:03] <czajkowski> It;s broken down into monthly tasks
[21:04] <czajkowski> if 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 ideas
[21:04]  * popey edits it a bit
[21:04] <czajkowski> Long term goals to help you plan for the future, this can consist of helping and guiding new members
[21:04] <czajkowski> anyone have any questons
[21:05] <czajkowski> itnet7: huats leogg care to join in
[21:06] <itnet7> czajkowski: I think you've covered it pretty well
[21:06] <czajkowski> THe guide has been translated but it'd be nice to see more translations
[21:07] <huats> czajkowski, actually I agree with itnet7 it covers a lot of area
[21:07] <czajkowski> This 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 teams
[21:07] <huats> I'll pass the URL to the french translation team
[21:07] <czajkowski> huats: thanks :)
[21:07] <czajkowski> ok moving on so
[21:07] <czajkowski> [topic] LoCo Team Re Approval Update
[21:07] <MootBot> New Topic:  LoCo Team Re Approval Update
[21:08] <itnet7> Maybe 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/LoCoTeamReApproval
[21:08] <MootBot> LINK received:  https://wiki.ubuntu.com/LoCoCouncil/LoCoTeamReApproval
[21:08] <itnet7> s/were/where/
[21:08] <czajkowski> the LoCo council has selected teams for this cycle to review.  It's random. Any team over 2 years is viewed.
[21:09] <czajkowski> As we cannot do every single team in one cycle we select a number, this time 30
[21:09] <czajkowski> if you team is NOT ON THE LIST - you don't need to worry.  You will be selected another time
[21:09] <czajkowski> Do not panic if you receive an email from us
[21:10] <czajkowski> One of the loco council members will contact you , that is your point of contact for the re approval process.
[21:10] <czajkowski> If you've any questions, just ask, if you want us to review your application before the meeting, just ask, We're here to help you
[21:10] <czajkowski> Does anyone have any questions regarding the process?
[21:11] <czajkowski> hmm not sure the silence is good, as there does seem to be a bit of confusion regarding this on the mailing list.
[21:11] <popey> I suspect not many loco team members are here
[21:11] <czajkowski> popey: possibly.
[21:12] <itnet7> that's what I was thinking as well
[21:12] <YoBoY> i'm here ;)
[21:12] <czajkowski> wonder do they know it's on
[21:12] <popey> :)
[21:12] <czajkowski> YoBoY: aloha!!! :)
[21:12] <popey> I dont think they care :(
[21:12] <YoBoY> hi :)
[21:13] <czajkowski> popey: 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 meetings
[21:13] <czajkowski> popey: I think this is something we should be looking into
[21:13] <huats> of course you are here YoBoY :)
[21:13] <popey> sure
[21:14] <czajkowski> I'll move onto the next topic as that's kinda more inline with it
[21:14] <czajkowski> [topic] How the LoCo Council can help you
[21:14] <MootBot> New Topic:  How the LoCo Council can help you
[21:14] <czajkowski> I guess the fact that there are very few team members here is something we should looking into
[21:14] <czajkowski> I 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 meetings
[21:15] <AlanBell> do you want team members here or point of contacts?
[21:15] <huats> I think both would be great :)
[21:15] <czajkowski> AlanBell: it's welcome to everyone. anyone who wants to learn more about the community, or take part in discussion
[21:16] <czajkowski> If the point of contacts are here, it would be great as they could/should be passing on information to their teams
[21:16] <czajkowski> as I have noticed many point of contacts not explain the re approval process to their teams
[21:16] <popey> we know they dont do that though
[21:16] <popey> (pass information on)
[21:16] <popey> from the loco-contacts list for example
[21:16] <czajkowski> popey: :( aye we do now
[21:16] <mhall119> do meeting minutes get sent to loco-contacts?
[21:16] <czajkowski> mhall119: we started doing that last cycle
[21:17] <mhall119> ok, I couldn't remember seeing any
[21:17] <czajkowski> So how can we get more teams to come here and take part
[21:17] <czajkowski> and
[21:17] <czajkowski> how can we make sure point of contacts are in fact passing on information to their teams
[21:18] <itnet7> czajkowski: you can mention it in your checkup talks, and we can blog about it
[21:18] <czajkowski> which is the whole point of a point of contact
[21:18] <czajkowski> itnet7: aye I think we the council should be blogging about this issue
[21:18] <AlanBell> well, 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] <czajkowski> There are 6 of us, so I think we should be able to increase the awareness of this
[21:18] <huats> czajkowski, I agree
[21:19] <huats> AlanBell, 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] <czajkowski> It's also a chance to raise issues and bring them to our attention
[21:20] <czajkowski> folks find us on IRC the whole time, but it would be nice to have them rasied here so more input can be made
[21:20] <YoBoY> i can't remember if you send an email to the loco ML to remember this meeting and invite them to come
[21:20] <huats> YoBoY, no I don't think either
[21:20] <czajkowski> YoBoY: that's true we should do that
[21:20] <huats> czajkowski, I can blog about it
[21:20] <popey> so we need to change perception of the meeting, and better communicate the purpose of it?
[21:20] <czajkowski> popey: yes
[21:20] <huats> popey, +1
[21:20] <popey> yet more reason for us to mail all the loco teams mailing lists?
[21:21] <huats> popey, indeed...
[21:21] <czajkowski> So 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] <huats> czajkowski, you mean the day before ?
[21:21] <czajkowski> huats: aye is that too short?
[21:21] <popey> we already know people a) dont read the loco contacts list, and b) people dont pass it on
[21:21] <AlanBell> perhaps communicate to the point of contacts that their attendance or the attendance of a representative from their loco is expected
[21:22] <huats> a bit short I think
[21:22] <popey> so i'm unconvinced how effective that would be
[21:22] <czajkowski> perhaps we could ask jono to blog about this
[21:22] <huats> I would prefer the friday before
[21:22] <czajkowski> people do read his blog and his tweets
[21:22] <popey> I am also unconvinced blogging is the way forward
[21:22] <czajkowski> is jono around, before I action him stuff
[21:22] <czajkowski> popey: ok, what would you suggest?
[21:22] <mhall119> I might have some suggestings that tie into the next agenda item
[21:22] <popey> i dont think we should be actioning anyone without figuring out the problem / solution first
[21:22] <huats> popey, well I think it is not a big action to blog and mail
[21:23] <huats> we can try out to see it there is any improvment :)
[21:23] <popey> ok, here's my thoughts..
[21:23] <czajkowski> popey: I think the lack of awareness is a large issue
[21:23] <huats> popey, go ahead :)
[21:23] <popey> do we really need people to be here to listen to us announce a wiki page?
[21:23] <popey> surely this can be better communicated via other means than irc
[21:23] <mhall119> I think the desire is for the LC to listen to team members, not the other way around
[21:24] <popey> sure, which brings me onto my next point
[21:24] <popey> they know where to find us, we have a mailing list, and people do use it
[21:24] <popey> of course if they want to discuss stuff we can do so in irc
[21:24] <popey> but it's not like we're inaccessible?
[21:24] <popey> or are we?
[21:25] <huats> popey, actually you are :P
[21:25] <czajkowski> popey: thats true, however, tis kinda hard to follow up on a pm, and folks only seem to poke the same people over and over
[21:25] <czajkowski> popey: not all of us are on IRC or run screen sessions so we get messages
[21:25] <mhall119> itnet7 keeps spending time on someting called "work"
[21:25] <itnet7> mhall119: :-p
[21:26] <huats> I think the clear misunderstood of the reapproval that people had faced lately and the number of email our mailing list received is quite explicit
[21:26] <czajkowski> I'd rather see teams coming here and engaging in discussion
[21:26] <paultag> Hey. Sorry I'm late
[21:26] <czajkowski> there seems to be a lack of discussion happening here and even on the mailing list
[21:26] <huats> on the other hand I have been quite suprised to see a team asking where to find me...
[21:26] <czajkowski> paultag: welcome :)
[21:27] <YoBoY> hi paultag
[21:28] <czajkowski> YoBoY: AlanBell mhall119 you're the only ones who are active here atm. What would you like to see happening? to get discussions going?
[21:29] <mhall119> well, this kind of ties into the meeting feature we're talking about for loco-directory
[21:29] <AlanBell> well I had no idea I didn't have to shut up :-)
[21:29] <mhall119> since loco-council in in the directory, it will be able to add meetings there, and add other teams to those meetings
[21:29] <paultag> Hey! Quiet-pants! Let's get some talk going or we might as well stop here!
[21:29] <itnet7> popey: 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-approvals
[21:29] <paultag> duanedesign: POKE! You're quite active in the community :)
[21:29] <paultag> Joeb454: Ya'here?
[21:29] <itnet7> not everyone would have to attend both
[21:29] <czajkowski> akgraner: where are you, you're usually a lot more active
[21:30] <czajkowski> itnet7: good point
[21:30] <mhall119> if 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 too
[21:30] <czajkowski> itnet7: at present folks just attend here for approvals
[21:30] <czajkowski> mhall119: *nods*
[21:30] <mhall119> czajkowski: 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 not
[21:30] <czajkowski> mhall119: would this be also like the UWN ( akgraner ) with the icals for meetins?
[21:30] <AlanBell> I just think a "who should attend" line somewhere might be useful
[21:30] <YoBoY> don't know... the re approval process is in its way for our locoteam, the wiki explain a lot, i haven't questions aout it yet
[21:30] <AlanBell> on the agenda
[21:31] <mhall119> czajkowski: UWN has a ical feed?  or do they want an ical feed?
[21:31] <akgraner> czajkowski, you are making my machine blink :-)  what's up?
[21:31] <itnet7> Well 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 solution
[21:31] <czajkowski> they are doing them
[21:31] <paultag> jacob: cjohnston, drubin, nigelb, Poke, ya'll -- We need some more talk on LoCo stuff. You guys around?
[21:31] <czajkowski> akgraner: wondeing why folks we know are active are not active in this session
[21:31] <cjohnston> ?
[21:31] <mhall119> czajkowski: since akgraner asked me for the meeting feature, I guess it would probably replace what UWN is doing
[21:31] <akgraner> ahh I am publishing the newsletter at the moment :-)
[21:32] <cjohnston> me too
[21:32] <popey> nice timing
[21:32] <akgraner> mhall119, nope won't replace what we do in UWN but it will give me a place to point people to for LoCo information
[21:32] <mhall119> ah, ok, what do you have ical feeds for now?
[21:33] <drubin> paultag: yes
[21:33] <czajkowski> ok 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] <czajkowski> I'll take that on
[21:33] <paultag> drubin: thanks :) -- LoCo council meeting, it's quiet. Can I convince you to stick around and throw your two cents in?
[21:33] <akgraner> UWN will report the development team meetings, move the LoCo meetings off the Fridge calendar and on to a LoCo Calendar instead
[21:33] <czajkowski> [action] czajkowski to mail loco contacts mailing list the Friday before the meeting to remind people this meeting is on
[21:33] <MootBot> ACTION received:  czajkowski to mail loco contacts mailing list the Friday before the meeting to remind people this meeting is on
[21:33] <mhall119> akgraner: okay, I understand now
[21:33] <drubin> paultag: sure I need to read the scroll back quick though
[21:33] <paultag> czajkowski: I should have CC'd contacts when I mailed the council ML
[21:34] <paultag> drubin: quite alright
[21:34] <akgraner> mhall119, awesome! :-)
[21:34] <czajkowski> popey: moving forward what would you suggest? for communication methods?
[21:35] <popey> I'm not sure, I wanted us to discuss it, rather than just say 'lets blog it'
[21:35] <popey> figure out what the best way forward is.. if that makes sense
[21:35] <huats> popey, makes sense
[21:36] <itnet7> definitely popey
[21:36] <AlanBell> fwiw I am unconvinced that blogging it is the solution, it won't be seen by people who are not yet involved in Ubuntu
[21:36] <czajkowski> popey: well I'd love to see discussions take place on the list
[21:36] <popey> AlanBell: I am not sure they are target audience anyway
[21:36] <paultag> AlanBell: well we are only worried with talking with contacts
[21:36] <czajkowski> I also btw tweet using #locoteams as do very few others, but it's interesting to follow and something we could push
[21:36] <paultag> AlanBell: contacts talk with lay members :)
[21:36] <popey> target is people who are already in loco teams, who need help, mentoring, direction etc
[21:36] <paultag> czajkowski: I like that
[21:37] <huats> czajkowski, good idea too
[21:37] <czajkowski> popey: true
[21:37] <drubin> czajkowski: Nice idea.
[21:37] <czajkowski> popey: I think we need to increase the awareness of this Council also - that it's not taboo to contact us.
[21:37] <huats> popey, I do beleive that people who are involved in LoCo teams are quite exposed to planet ubuntu
[21:37] <paultag> Wonder if we could have a tweet version of planet ubuntu
[21:38] <czajkowski> If folks know they can contact us about anything, bouce a loco idea off us or just need a hand, we're here to help
[21:38] <czajkowski> paultag: no!
[21:38] <huats> popey, I am not saying it is THE solution, but cool be part of it
[21:38] <paultag> czajkowski: it will support identi.ca too!
[21:38] <popey> sure
[21:38] <huats> popey, I meant can be part of it
[21:38] <mhall119> paultag: status.net
[21:38] <paultag> mhall119: well it's all the same API
[21:39] <popey> ok these are technical details
[21:39] <paultag> aye
[21:39] <AlanBell> popey: 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 entries
[21:39] <mhall119> paultag: but status.net can have separate domains
[21:39] <popey> the main issue is getting information out to members of locos around the world
[21:39] <paultag> mhall119: another issue
[21:39] <paultag> +1 popey
[21:39] <huats> AlanBell, of course
[21:39] <czajkowski> popey: +1
[21:39] <mhall119> paultag: you can ask akgraner about it
[21:39] <drubin> popey: I think a biggest issue is gettting the info out to the rest of the people.
[21:39] <paultag> mhall119: we'll do that after the meeting if that's the direction we go with :)
[21:40] <drubin> I think ubuntu hour was one of the greatest things our loco ever did.
[21:40] <czajkowski> popey: is it something we should be mandating points of contacts to pass mails from us to loco contacts list to their teams list
[21:40] <paultag> drubin: Yes!!!
[21:40] <czajkowski> Or
[21:40] <czajkowski> something that the loco council should indeed be mailing LoCo teams mailing list wiht
[21:40] <drubin> It has started up a Lug in our area to have their beer evenings again!! it was awsome
[21:40] <czajkowski> *with
[21:40] <czajkowski> I know this kinda topic came up at UDS
[21:40] <drubin> paultag: More global jams and bug things
[21:41] <popey> I still think we should mail out to all the loco mailing lists
[21:41] <paultag> czajkowski: 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] <czajkowski> should the loco council post to the Teams mailing list information we want teams to have for definate ie, re approval??
[21:41] <paultag> popey: me too
[21:41] <mhall119> czajkowski: I'm gonna need to leave in about 15 minutes, will there be time for my agenda item?
[21:41] <drubin> like 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 keen
[21:41] <AlanBell> do you think there should be a "who should attend" section on https://wiki.ubuntu.com/LoCoCouncil/Agenda
[21:41] <popey> yes al
[21:41] <czajkowski> AlanBell: yes
[21:41] <popey> +tab
[21:41] <czajkowski> popey: see my comment above
[21:41] <YoBoY> drubin: you can organize that without the global event thing ;)
[21:42] <czajkowski> mhall119: should be
[21:42] <akgraner> paultag, let me get UWN published - and I'll be happy to answer question about status.net :-)
[21:42] <drubin> YoBoY: you missed my point, when it is global people are always more keen! :)
[21:42] <paultag> akgraner: we'll do it after the meeting, deal?
[21:42] <drubin> and yes we do.
[21:42] <paultag> akgraner: :)
[21:42] <akgraner> nods
[21:42] <YoBoY> drubin: ok
[21:42] <huats> czajkowski, I think we cannot completly rely on loco contacts
[21:42] <huats> we have seen that of a few occasions lately
[21:43] <drubin> ;/ that is sad
[21:43] <paultag> huats: I agree
[21:43] <czajkowski> huats: 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 attention
[21:43] <czajkowski> so ireland france uk would get the mail from us
[21:44] <paultag> oi oi, Ohio too!
[21:44] <mhall119> everyone except Ohio ;)
[21:44] <paultag> :P
[21:44] <drubin> as long as it is low traffic
[21:44] <czajkowski> paultag: I wasn;t going to list all of the teams out! I'd be here all evening my dear!
[21:44] <paultag> drubin: +1, and major stuff :)
[21:44] <paultag> czajkowski: :)
[21:44] <popey> heh
[21:44] <czajkowski> drubin: it'd be only for important mails
[21:44] <drubin> 90% of the stuff on loco-contacts is useless for most locos
[21:44] <huats> czajkowski, this is something we have envisaged : to have a direct access to loco mailing list
[21:45] <drubin> czajkowski: Just making it noted but ye I assumed it would be
[21:45] <czajkowski> well it'd take us the loco council being added to all of the teams
[21:45] <czajkowski> drubin: :)
[21:45] <paultag> czajkowski: could we sneak something with the launchpad group?
[21:45] <czajkowski> paultag: leave lp alone :p
[21:45] <paultag> czajkowski: we already have a list, maintaining it is hard IMHO
[21:45] <drubin> also just so you know that most of the teams don't use LP for thier mailing lists
[21:45] <paultag> czajkowski: well shucks, it would save us time!
[21:45] <czajkowski> popey: would it take much for us to be added to all of the teams ??
[21:45] <paultag> drubin: I know, but if their contact addy was the ML we would be all set
[21:46] <popey> it would just take 5 mins subscribing to each mailman list
[21:46] <paultag> drubin: us --> lp --> lp teams --> lists.ubuntu for each team
[21:46] <popey> and set them all to nomail
[21:46] <popey> so we dont get all their mail, we just send mail to their list as a subscriber
[21:46] <drubin> well maybe it would be better to subscribe the council to each team.
[21:46] <popey> yup
[21:46] <AlanBell> agenda fixed.
[21:46] <czajkowski> ok, how does that sound to the council, going forward for important mails and annoucements we send our mail directly to the teams ??
[21:47] <paultag> I'll +1 it, even though it's more work :)
[21:47] <popey> I'd check thats okay with jono / the cc
[21:47] <popey> its not much work tbh
[21:47] <paultag> I'm kidding popey :)
[21:47] <huats> czajkowski, +1 for me too
[21:47] <paultag> I'm all for it. I think it would help a lot
[21:47] <paultag> Just worried about RE mail, but that is OK.
[21:47] <itnet7> sounds good to me
[21:47] <czajkowski> [action] popey to investigate The LoCo Council being added to all LoCo teams mailing list so the Council can post directly to them
[21:47] <MootBot> ACTION received:  popey to investigate The LoCo Council being added to all LoCo teams mailing list so the Council can post directly to them
[21:47] <huats> popey, you are right to ask for it with CC and jono
[21:47] <drubin> +1 fro popey
[21:48] <czajkowski> ok does anyone have any further comments as I'd like to move onto mhall119 topic please
[21:48] <drubin> any thing >1 per month IMHO is to high trafficthough
[21:48] <czajkowski> [topic] LoCo-Directory Meeting Feature
[21:48] <MootBot> New Topic:  LoCo-Directory Meeting Feature
[21:48] <czajkowski> mhall119: you're up
[21:48] <mhall119> thanks czajkowski
[21:49] <czajkowski> [link] https://wiki.ubuntu.com/LoCoDirectory/MeetingFeature
[21:49] <MootBot> LINK received:  https://wiki.ubuntu.com/LoCoDirectory/MeetingFeature
[21:49] <mhall119> so, after releasing the event tracking feature on loco.ubuntu.com, we've had several people ask us about using it to track IRC meetings
[21:49]  * mhall119 is one of the loco-directory devs
[21:49] <mhall119> the current event feature is really specific to physical meetups, so we're looking into creating an IRC meeting feature to compliment it
[21:50] <mhall119> this feature would let teams schedule meetings, give the channel they will be held in, provide a structured list of agenda items, etc
[21:50] <mhall119> it would largely replace the use of Wiki pages for these things
[21:50] <mhall119> wiki pages would still be used to expand in detail on specific agenda items
[21:51] <mhall119> once 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 minutes
[21:51] <AlanBell> I 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 back
[21:51] <czajkowski> So 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 LD
[21:52] <paultag> I'm here, but eating dinner. Don't mistake me for missing!
[21:52] <huats> ok czajkowski
[21:52] <huats> you were right to do so
[21:52] <mhall119> we 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 so
[21:53] <czajkowski> I 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 place
[21:53] <czajkowski> mhall119: so that;s kinda forcing people by the fact that most do.
[21:53] <AlanBell> the 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 this
[21:53] <mhall119> so far the reception to the events feature has been very positive
[21:53] <paultag> mhall119: can you talk with wiki?
[21:53] <czajkowski> Also for the council to review teams, to have information in one place and not all over the place does help
[21:53] <mhall119> paultag: not really, because wiki's aren't structured
[21:53] <paultag> mhall119: perhaps we can have loco-directory write to /loco-direcotory/automated/team/event/
[21:53] <paultag> mhall119: and from there include it on the page of the team
[21:53] <mhall119> we could post to a wiki, I suppose, but not reliably read from it
[21:54] <paultag> mhall119: all you have to work out is how to auth
[21:54] <paultag> mhall119: you don't need to read
[21:54] <mhall119> then yes
[21:54] <mhall119> or a Moin macro can be made to retrieve data from the directory and format it for the wiki
[21:54] <paultag> mhall119: perhaps move it all to loco-directory that way
[21:54] <czajkowski> I 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 either
[21:55] <mhall119> now, 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 meetings
[21:55] <paultag> czajkowski: hopefully it won't impact teams that don't use it
[21:55] <mhall119> also, for reapprovals, the loco-council could schedule the meeting and include each team that is up for re-approval
[21:56] <mhall119> it 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 features
[21:56] <mhall119> I don't think that's really forcing them though, just offering a better option
[21:56] <mhall119> as long as Mootbot can continue to take manual direction
[21:57] <mhall119> it shouldn't interfere with their current methods
[21:57] <czajkowski> mhall119: 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 either
[21:57] <mhall119> but, it would mean akgraner would have to pull from loco-directory and the wiki for UWN
[21:57] <mhall119> czajkowski: I agree, and I would like to see more discussion about it
[21:57] <paultag> mhall119: well right now we have 100% of the teams on the wiki
[21:57] <popey> creating it is fine, forcing it on locos isnt czajkowski, i agree
[21:57] <mhall119> unfortunately there's just been a lot of silence
[21:57] <paultag> mhall119: we are going to work on migrate, but it takes time, and we can't rush new things
[21:57] <drubin> mhall119: 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 present
[21:58] <mhall119> we've had several requests for the feature, and one complaint
[21:58] <czajkowski> popey: right, which is what is gonna happen :(
[21:58] <czajkowski> mhall119: I've also seen no discssion either
[21:58] <mhall119> drubin: yes, feel free to bring those up in the spec, it's still in the planning stage
[21:58] <czajkowski> mhall119: my complaint is that disussion hasn't happened
[21:58] <mhall119> czajkowski: understood, I'm trying to change than
[21:58] <mhall119> that
[21:59] <czajkowski> mhall119: I know
[21:59] <huats> czajkowski, but I fear that there might have no discussion...
[21:59] <mhall119> my feeling is, if there is little interest, no objection, and a lot of indifference, that's enough to justify doing it
[21:59] <czajkowski> huats: so we're back at tonights earlier topic :)
[21:59] <czajkowski> mhall119: :o
[22:00] <AlanBell> I am unsure why there is a concern about this being forced on teams
[22:00] <huats> on 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] <mhall119> the biggest impact would be on akgraner and UWN, as they would have to pull from two sources if teams continued using the wiki
[22:00] <paultag> that's not true mhall119
[22:00] <drubin> the point about scrum and stories is developsomething small, and interate.
[22:00] <drubin> if it doesn't work change it
[22:01] <paultag> mhall119: you can not pull from the loco-directory, only pull from the loco directory or both
[22:01] <mhall119> I don't follow
[22:01] <paultag> mhall119: I like the loco-directory, but we need to work on a slow migraton. For now the Wiki is the most upto date source
[22:01] <czajkowski> mhall119: 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 could
[22:01] <paultag> mhall119: that's why I'm thinking a wiki bridge might aid in adoption
[22:02] <czajkowski> I'd rather see more of a focus getting teams to use the LD and posting events to it
[22:02] <czajkowski> before meetings
[22:02] <drubin> +1 from my side
[22:02] <huats> czajkowski, I agree
[22:02] <mhall119> paultag: would we be allowed to add a Moin macro to the Ubuntu wiki servers?
[22:02] <drubin> there seems to be an perception that it is hard to post an event
[22:02] <czajkowski> huats: I think the focus for this cycle should be getting teams to use the LD, adding their events and detals on it
[22:02] <drubin> or even sign up to an event
[22:02] <paultag> mhall119: perhaps, but it's really easy to do it the other way -- why not just write to wiki pages
[22:02] <czajkowski> and not meetings
[22:03] <mhall119> drubin: how so?
[22:03] <paultag> mhall119: just set up /loco-directory/automated/ blah blah
[22:03] <huats> czajkowski, I agree with you
[22:03] <mhall119> paultag: we would need to authenticate to the wiki
[22:03] <czajkowski> huats: :)
[22:03] <paultag> mhall119: trivial
[22:03] <drubin> mhall119: I have no idea just does ;/
[22:03] <mhall119> paultag: okay then, would you help us with that part?
[22:03] <drubin> mhall119: I am not saying I feel that it is the feeling I get from other people
[22:03] <huats> czajkowski, 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 cycle
[22:05] <drubin> Ok 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] <czajkowski> drubin: ok we;ll be doing that in future
[22:05] <paultag> ty drubin
[22:05] <czajkowski> drubin: thanks for coming
[22:05] <mhall119> I need to head out too, are there any questions I can answer before I go?
[22:06] <mhall119> feel free to keep discussing it after I'm gone, I'll read the logs from home
[22:06] <paultag> mhall119: can you work out the practical way of briding wiki and ld and get back to us?
[22:07] <mhall119> paultag: as long as the intention is to move forward with this feature if such a bridge is made
[22:07] <mhall119> otherwise it'd just be a waste of time
[22:07] <paultag> mhall119: it is
[22:07] <AlanBell> paultag: 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] <mhall119> ok, I will ask you later how to get LD authenticating to the wiki
[22:07] <paultag> AlanBell: well if the events on a wiki page for a team was pulling from LD it would be more up to date then anything else
[22:07] <AlanBell> and yeah, I have no idea how to do the auth bit
[22:07] <czajkowski> does anyone else have any comments ?
[22:08] <paultag> mhall119: thanks rockstar
[22:08] <AlanBell> paultag: ah, ok for the events bridge, gotcha.
[22:08] <paultag> AlanBell: aye
[22:08] <mhall119> I'm in #ubuntu-locoteams or #ubuntu-us-fl all the time if anybody has other questions
[22:08] <mhall119> otherwise, put your ideas/concerns on the spec page
[22:08] <mhall119> https://wiki.ubuntu.com/LoCoDirectory/MeetingFeature
[22:08] <czajkowski> mhall119: thanks
[22:08] <mhall119> thanks everybody
[22:09] <paultag> ty mhall119
[22:09] <huats> thanks everyone
[22:09] <czajkowski> Has 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 wiki
[22:09] <MootBot> ACTION received:  paultag write up mins and post to contacts mailing list and update wiki
[22:09] <paultag> :)
[22:09] <czajkowski> #endmeeting
[22:09] <MootBot> Meeting finished at 16:09.
[22:10] <czajkowski> paultag: in case you think I'd forgotten
[22:10] <popey> blimey
[22:10] <paultag> :D
[22:10] <itnet7> :-)
[22:10] <paultag> czajkowski: :P
[22:10] <huats> :)
[22:10] <popey> i expected us to be here for another hour  :)
[22:10] <czajkowski> popey: I can restart meeting if you;ve other items ?
[22:11] <popey> heh
[22:12] <paultag> Well, I'm off to cut my lawn. Thanks, all!