[10:04] <persia> Is this one of those Tuesdays?
[10:06] <nigelb> persia: the last week was
[10:07] <nigelb> persia: unfortunately, everyone except elky didn't think so
[10:07] <persia> Ah, then next week will be.
[10:08] <elky> i think we've missed enough we can probably agree to any tuesday and reset it from there.
[10:09] <persia> Apparently our next scheduled meeting is 4th January.  Shall we have one 15th February then, and try to get back with the program from there?
[10:10] <head_victim> Heh almost enough for a quorum now?
[10:11] <nigelb> When does more people get added to the board again?
[10:11] <persia> head_victim, perhaps, but not in a way that is useful: we're clearly fail to attract candidates in a way that is useful.
[10:31]  * persia , in the absence of clear comment, updates the wiki page to claim a date
[14:57] <kees> mdz, pitti, cjwatson: meeting in a few minutes. can't find Keybuk or sabdfl, though.
[14:57] <pitti> o/
[14:58] <cjwatson> here, more or less
[14:58] <mdz> kees, clan mailed saying sabdfl wouldn't make it
[14:58] <mdz> (t-b@)
[14:59] <kees> mdz: ah, thanks.
[14:59] <mdz> kees, I tidied up the agenda based on pitti's minutes from last time
[15:00] <kees> mdz: oh, excellent
[15:01] <cjwatson> (I've just moderated clan's mail)
[15:01] <kees> #startmeeting
[15:01] <MootBot> Meeting started at 09:01. The chair is kees.
[15:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:01] <kees> [TOPIC] action review
[15:01] <MootBot> New Topic:  action review
[15:01] <kees> mdz - Set the release manager to ubuntu-release
[15:02] <mdz> kees, so I'm confused about this
[15:02] <mdz> the release manager for natty is already ubuntu-release
[15:02] <mdz> is that what was meant here, or did it mean something else?
[15:03] <kees> I think that's what was meant; there were the notes from the rally TB
[15:03] <cjwatson> I think it wasn't when that action was taken
[15:03] <mdz> ok, so that's done then
[15:03] <kees> ok, next
[15:03] <kees> mdz - Review ubuntu-drivers membership and make sure it includes (only) people who need to manage blueprints
[15:03] <mdz> I haven't reviewed ubuntu-drivers
[15:03] <mdz> I think someone else should review ubuntu-release
[15:03] <kees> ok, carried over
[15:04] <kees> mdz - Review ubuntu-release membership
[15:04] <kees> carried over
[15:04] <kees> mdz - Set the owner/maintainer to techboard
[15:04] <mdz> done
[15:04] <cjwatson> the ubuntu-release membership looks correct to me
[15:04] <kees> mdz - announce something to ubuntu-devel-announce
[15:04] <mdz> not done
[15:04] <kees> bdmurray - file bug about bug supervisor not being able to set bug reporting guidelines for Ubuntu as a whole
[15:04] <kees> I think this was done, but I can't find the bug currently
[15:05] <pitti> u-release> not sure about Iulian and Stefan (whether they still want to be involved), but otherwise it looks fine to me
[15:05] <kees> [action] kees will follow up with bdmurray about his action
[15:05] <MootBot> ACTION received:  kees will follow up with bdmurray about his action
[15:05] <kees> pitti - check with James Troup about current quality experience of pool.ntp.org
[15:05] <pitti> done, will present the details in the actual topic
[15:05] <kees> okay
[15:05] <kees> pitti - add TB as vendor contact point for http://groups.google.com/group/ntppool-vendors?pli=1
[15:05] <kees> saw that was done
[15:05] <pitti> done
[15:06] <kees> okay, were there any other actions we needed to review that weren't already listed?
[15:06] <kees> [topic] Default ntpd configuration  https://bugs.launchpad.net/bugs/104525
[15:06] <MootBot> New Topic:  Default ntpd configuration  https://bugs.launchpad.net/bugs/104525
[15:07] <kees> where does this stand currently?
[15:07] <pitti> I talked to James about it
[15:07] <mdz> I brought it up, but I missed the last meeting
[15:07] <pitti> we reviewed that a couple of years ago, and then it was still not very reliable
[15:08] <pitti> but these days they have a pretty good probing system and network, and throw servers out of the rotation when they are off by .1 s or more (checked three times an hour)
[15:08] <pitti> so from a reliability POV James was okay with it now
[15:08] <pitti> his main concern is security
[15:08] <pitti> i. e. a server could send out bad times to all clients except to the one that is doing the probing
[15:09] <mdz> what's the worst case scenario?
[15:09] <pitti> so that you could infiltrate the network with several servers which send out the wrong time
[15:09] <pitti> that's quite a lot of effort, of course
[15:09] <pitti> the advantage is that it provides nice geolocation support, i. e. selects a server near you, and has a large round-robin network
[15:10] <pitti> it would be interesting to see whether they plan DNSSEC support, but then again ntp.u.c. doesn't have that either
[15:10] <mdz> pitti, quite a lot of effort, yes, and what is there to gain?
[15:10] <mdz> seems like DoS
[15:10] <cjwatson> I think we should remember that this is replacing a hardcoded list of server names
[15:10] <cjwatson> which we never maintain AFAIK
[15:11] <cjwatson> I have a hard time seeing how it wouldn't be an improvement
[15:11] <kees> apt has rewind and staleness protections, so the worst-case with targetted time attacks would be a freeze attack convincing apt to never update.
[15:11] <mdz> kees, and most users probably inflict a much more successful attack on themselves by not installing updates ;-)
[15:11] <pitti> you could also envision running somethign like ebay on a machine like that, and tricking that into thinking that an auction is still happening when it shoudln't be any more, etc.
[15:11] <kees> mdz: right
[15:12] <pitti> i. e. there are certaily interesting attacks, but it still by and large feels theoretical to me
[15:12] <pitti> (and it hasn't happened so far)
[15:12] <kees> yup
[15:12] <mdz> pitti, on the plus side, if there are millions of clients using that pool, an attempt to subvert it would likely be noticed quickly
[15:12] <pitti> so in summary, from what I've heard from the admins there and after discussion with James, I'm happy about the proposal
[15:12] <cjwatson> anyway, this discussion has been had in the bug, see e.g. comment 6
[15:12] <pitti> i. e. to have X.ubuntu.pool.ntp.org and ntp.u.c. in the default config
[15:13] <mdz> wfm
[15:14] <cjwatson> (replacing> in gnome-system-tools, I mean)
[15:14] <cjwatson> I'm also happy for us to go ahead at this point; especially security-sensitive sites are still free to use their own NTP servers, and they may well already do so
[15:15] <kees> right. I'd agree as well.
[15:15] <pitti> cjwatson: indeed, the list in g-s-t is quite bad; we should IMHO replace that in any case, even if we'd not change (or revert) the ntpd.conf list)
[15:15] <pitti> so that there's only very little reason to change it at all
[15:17] <kees> should we specifically vote on this?
[15:18] <mdz> I think we just did
[15:18] <cjwatson> we seem to have straw-poll consensus
[15:18] <kees> okay, so the proposal would be to switch the default ntp servers to {0,1,2,3}.ubuntu.pool.ntp.org, yes?
[15:19] <pitti> kees: plus ntp.u.c. for ntpd.conf
[15:19] <pitti> (at least that was the proposal we discussed last time)
[15:20] <kees> pitti: ntpd.conf would get {0,1,2,3}.ubuntu.pool.ntp.org and ntp.u.c?
[15:20] <pitti> that's how I understood it, anyway; perhaps just three from the pool
[15:21] <pitti> then if ntp.org would fail, we'd still have the ubuntu one
[15:21] <kees> [vote] switch the default ntp servers to {0,1,2,3}.ubuntu.pool.ntp.org plus ntp.ubuntu.com
[15:21] <MootBot> Please vote on:  switch the default ntp servers to {0,1,2,3}.ubuntu.pool.ntp.org plus ntp.ubuntu.com.
[15:21] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[15:21] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[15:21] <kees> +1
[15:21] <MootBot> +1 received from kees. 1 for, 0 against. 0 have abstained. Count is now 1
[15:21] <mdz> +1
[15:21] <MootBot> +1 received from mdz. 2 for, 0 against. 0 have abstained. Count is now 2
[15:21] <pitti> +1
[15:21] <MootBot> +1 received from pitti. 3 for, 0 against. 0 have abstained. Count is now 3
[15:22] <mdz> I assume someone has checked that they are prepared to handle this volume of clients...
[15:22] <pitti> they seemed happy enough about it
[15:22] <cjwatson> +1
[15:22] <MootBot> +1 received from cjwatson. 4 for, 0 against. 0 have abstained. Count is now 4
[15:22] <pitti> "they" -> ntp.org admins, haven't checked the servers obviously
[15:22] <kees> [end]
[15:23] <kees> er
[15:23]  * cjwatson eyes up https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/715141 and wonders if pool.ntp.org does IPv6 ...
[15:23] <kees> [endvote]
[15:23] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[15:23] <pitti> [etov]? :-)
[15:23] <kees> $ host -t AAAA 2.ubuntu.pool.ntp.org
[15:23] <kees> 2.ubuntu.pool.ntp.org has no AAAA record
[15:24] <cjwatson> http://lists.ntp.org/pipermail/pool/2010-October/005234.html etc.
[15:24] <MootBot> LINK received:  http://lists.ntp.org/pipermail/pool/2010-October/005234.html etc.
[15:24] <kees> okay, that passed. who wants to implement it?
[15:25] <pitti> I'm happy to take g-s-t
[15:25] <mdz> jdstrand touched ntp last ;-)
[15:25] <pitti> want to coordinate a bit with upstream there
[15:25] <jdstrand> hey now
[15:25] <jdstrand> :)
[15:26] <pitti> but it's by and large sponsoring, the bug even has patches for both already
[15:26] <kees> pitti: I think it's best for 1 person to do the changes, regardless of package. can you take both?
[15:26] <jdstrand> if the bug has everything in it, and the vote passed, I can do it now
[15:26] <pitti> kees: can do, I just don't know much about testing ntpd
[15:26] <jdstrand> as it happens, I am patch piloting as we speak
[15:26] <kees> pitti: delegating to jdstrand works too :)
[15:26] <mdz> patch pilot!
[15:27] <pitti> jdstrand: I'll leave ntp to you then, and take g-s-t
[15:27] <jdstrand> ack
[15:27] <kees> [action] pitti to update g-s-t for new ntp pool
[15:27] <MootBot> ACTION received:  pitti to update g-s-t for new ntp pool
[15:27] <kees> [action] jdstrand to update ntp for new ntp pool
[15:27] <MootBot> ACTION received:  jdstrand to update ntp for new ntp pool
[15:27] <kees> jdstrand: to catch you up slightly, be sure that the to-be-sponsored ntp debdiff includes ntp.ubuntu.com as the final fall-back too.
[15:28] <jdstrand> ok
[15:28] <kees> okay, that topic is done...
[15:28] <kees> jdstrand: thanks!
[15:28] <kees> [topic] the mailing list archive for anything we missed
[15:28] <MootBot> New Topic:  the mailing list archive for anything we missed
[15:28] <jdstrand> sure :)
[15:29] <kees> I don't see anything from the mailing list. does anyone else see anything?
[15:30] <mdz> looking
[15:30] <mdz> is this utf8 thing resolved?
[15:30] <mdz> bug 666565
[15:31] <mdz> looks clear apart from that
[15:31] <kees> it doesn't seem like the TB needs to be involved in that bug?
[15:31] <mdz> can we unsub then?
[15:32] <kees> done
[15:32] <kees> [topic] Check up on community bugs
[15:32] <MootBot> New Topic:  Check up on community bugs
[15:33] <kees> I see this: https://bugs.launchpad.net/ubuntu-community/+bug/374900
[15:33] <kees> this is from long ago, IIRC.
[15:34] <cjwatson> I took an action for that at one point, but my head is filled with despair any time I contemplate it
[15:34] <cjwatson> I hate legal stuff
[15:34] <kees> hah
[15:34] <cjwatson> so I don't really know what to do, I could promise to do it but history suggests I may never get to it.  Can I punt?
[15:35] <mdz> let someone else worry about it for 2 weeks?
[15:35] <mdz> perhaps someone who isn't here today ;-)
[15:36] <mdz> looks like someone needs to get in touch with upstream
[15:36] <kees> we can punt if that's the way to go; it looks pretty clearly like the encoder package need to be removed.
[15:36] <kees> *needs
[15:36] <mdz> unless upstream agrees to fix it?
[15:36] <kees> but I will add it to the agenda for next time and we can move forward.
[15:37] <cjwatson> sorry
[15:38] <kees> [topic] other agenda items
[15:38] <MootBot> New Topic:  other agenda items
[15:38] <kees> I'd like to bring up moving the TB meeting by an hour or two. Probably 1700UTC would be best for Keybuk, based on his last TB email about his current schedule.
[15:39] <kees> I would like it moved away from 7am too, but I can usually make it.
[15:39] <cjwatson> 1700 is fine by me
[15:39] <mdz> still on tuesdays?
[15:39] <pitti> conflicts with desktop team meeting, so I'd need to sit in two in parallel
[15:40] <mdz> I have a tricky-to-move weekly meeting at that time
[15:40] <mdz> could do that time on mon or wed
[15:40] <pitti> I could do 1700 on Thu
[15:41] <cjwatson> I can't do Wed afternoon
[15:41] <cjwatson> Mon or Thu at that time would be OK
[15:41] <mdz> pitti, could you do mon?
[15:41] <cjwatson> (it's right after the 10.04.2/SRU/Natty interlock meeting, but I think that should be OK)
[15:42] <pitti> we have the SRU/10.04.2 meetings on Monday around that time
[15:42] <pitti> and after that I usually have dinner and then sports
[15:43] <pitti> so, while it would be very inconvenient, and I couldn't prepare for it, it'd be technically possible
[15:43] <pitti> I'd much prefer Thursday, though
[15:43] <mdz> I could do Thu but only if we go to alternate weeks
[15:43] <mdz> I have a 2-weekly meeting this week at that time
[15:44] <mdz> so we would need to change phase
[15:44] <pitti> phase doesn't matter much for me
[15:44] <kees> due to DST, the earliest I can do Thu is 1800
[15:44] <pitti> don't we usually move it an hour earlier during summer anyway?
[15:45] <kees> pitti: no, we recently tied it to UTC
[15:45] <mdz> take this to the mailing list maybe? we will need input from the other members as well
[15:45] <pitti> ah
[15:45] <kees> mdz: yeah, good idea.
[15:45] <pitti> 1800 UTC would be 2000 local in summer
[15:45] <kees> [action] kees - bring up TB rescheduling on mailing list
[15:45] <MootBot> ACTION received:  kees - bring up TB rescheduling on mailing list
[15:45] <pitti> set up a doodle?
[15:45] <kees> yeah
[15:45] <kees> okay, any other topics?
[15:46] <bdmurray> I filed that bug asked about earlier
[15:46] <kees> I'll leave Keybuk as chair for next time
[15:46] <bdmurray> its bug 703002
[15:46] <kees> bdmurray: ah, excellent. that was my memory too; do you have the bug # handy?
[15:46] <kees> excellent, thanks
[15:47] <mdz> kees, I think it's sabdfl's turn to chair
[15:47] <kees> mdz: oh, okay. it's been Keybuk's the last two, IIRC.
[15:47] <kees> anyway, sure, sabdfl it is.
[15:48] <kees> okay, that's a wrap then.
[15:48] <kees> thanks everyone!
[15:48] <pitti> thanks everyone
[15:48] <kees> #endmeeting
[15:48] <MootBot> Meeting finished at 09:48.
[15:53] <kirkland> o/
[15:55] <zul> hi
[15:56] <smoser> o/
[15:57] <RoAkSoAx> \o/
[15:57] <robbiew> o/
[15:58] <ttx> \o
[15:58] <JamesPage> o/
[15:58] <Daviey> o/
[15:58] <soren> _o_
[15:58] <JamesPage> ttx: feeling better?
[15:59] <ttx> JamesPage: slightly. I'm taking forever to recover
[15:59]  * smb \o
[15:59] <Daviey> ttx, :(
[15:59] <ttx> JamesPage, Daviey: how was FOSDEM ?
[15:59] <Daviey> ttx, good... tiring .. good... you were missed.
[16:00] <ttx> Daviey: not enough free beer ?
[16:00] <JamesPage> ttx: not much free beer :-(
[16:00] <SpamapS> o/
[16:00] <Daviey> ttx, maybe too much \;-0
[16:01] <JamesPage> shall we get started?
[16:01] <robbiew> yes
[16:01] <JamesPage> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is JamesPage.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:01] <JamesPage> [TOPIC] Review ACTION points from previous meeting
[16:01] <MootBot> New Topic:  Review ACTION points from previous meeting
[16:02] <JamesPage> So there where no actions from last weeks meeting....
[16:02] <SpamapS> \o/
[16:02] <Daviey> yuppie
[16:02] <JamesPage> [TOPIC] Natty Development
[16:02] <MootBot> New Topic:  Natty Development
[16:02] <JamesPage> Hows Alpha 2?
[16:02] <SpamapS> should we be iso testing
[16:02] <SpamapS> ?
[16:02] <Daviey> not a good story for eucalyptus atm
[16:03] <JamesPage> still FTBFS?
[16:03] <Daviey> think i solved that
[16:03] <Daviey> but ftbfs in archive
[16:03] <Daviey> and some dhcpd issues
[16:04] <zul> sounds like fun
[16:04] <Daviey> :/
[16:04] <Daviey> Regarding ISO testing... has everyone at least try  installing A2?
[16:04] <JamesPage> fixable?
[16:04]  * robbiew needs to summarize A2 and put up the plan for A3 this week
[16:05] <Daviey> JamesPage, yeah.. will be fixed this week..
[16:05] <JamesPage> Not yet: the daily ISO testing looks OK at the moment (http://hudson.qa.ubuntu-uk.org/)
[16:05] <smoser> i somewhat plan on installing A2 today on netbook.
[16:05]  * Daviey needs to talk to upstream
[16:06] <JamesPage> So back to SpamapS original question - should we be ISO testing or do we need todo that closer to A3?
[16:06] <Daviey> Generally A2 hasn't shown any kitten killers for me
[16:07] <Daviey> (except euca)
[16:07] <SpamapS> virt-manager is quite broken right now in natty.. so that makes iso testing a little more of a pain for me. :-P
[16:07] <zul> JamesPage: yes we should
[16:07] <RoAkSoAx> SpamapS: TestDrive?
[16:07]  * SpamapS could do virtualbox I suppose
[16:07] <RoAkSoAx> :P
[16:07] <SpamapS> RoAkSoAx: I'll look into it
[16:07] <Daviey> Those with real hardware available... is pretty useful to use compared to pure virtualised
[16:08] <zul> *cough* vmware *cough* ;)
[16:08] <Daviey> i've seen some nasty kernel bugs on my desktop install... and waiting for some serverish ones to hurt.
[16:08] <JamesPage> Sounds like thats a specific action for this week
[16:08] <Daviey> +1
[16:08]  * SpamapS 's only real hardware available is an old apple G5
[16:09] <smoser> you do know that A2 shipped, right ?
[16:09] <smoser> its kind of late to worry about dead kittens
[16:09] <robbiew> no kidding
[16:09] <robbiew> time to bury those and move on
[16:09] <JamesPage> [ACTION] ALL:  ISO testing (including as much real hardware as possible) to smooth the way to A3!
[16:09] <MootBot> ACTION received:  ALL:  ISO testing (including as much real hardware as possible) to smooth the way to A3!
[16:10] <SpamapS> in maverick we were getting hounded to do ISO tests.. this time I've heard nothing about iso testing. Just wondering if and when we should do iso tests. :-P
[16:10] <Daviey> yeah.. but we need to start hammering it to find the kittens... not save them :)
[16:10] <ttx> SpamapS: I wonder who did the hounding
[16:10] <RoAkSoAx> lol
[16:10] <robbiew> what does hggdh do?
[16:10] <SpamapS> ttx: some uppity frenchman
[16:10] <ttx> SpamapS: the worst kind
[16:10] <Daviey> ttx, you have been missed
[16:11] <JamesPage> Anything else for Natty dev at this point in time?
[16:11] <robbiew> seriously...if you are on the server team and you have to be hounded to test your own iso at milestone...that's a bit concerning
[16:11] <Daviey> i don't think hggdh has been able to test work loads... just installation.
[16:11] <zul> well installations was the only thing that was tested for the longest time
[16:11] <hggdh> on UEC? (sorry)
[16:11] <ttx> robbiew: +1. Even with a professional hounder, Hounding is no fun
[16:12] <Daviey> hggdh, generally.
[16:12] <robbiew> right
[16:12] <Daviey> hounding != co-ordination
[16:12] <hggdh> we are still prepping some automated tests -- based on LTP, and others
[16:12] <hggdh> and, on Hudson (or Jenkins) we are running pretty much all of trhe ISO tests
[16:12] <RoAkSoAx> hggdh: what about the powernap issue?
[16:13] <Daviey> hggdh, maybe not now... but could you and JamesPage give us some deeper insight at some point?
[16:13] <SpamapS> robbiew: well the cloud doesn't use iso's ;)
[16:13] <hggdh> Daviey: certainly
[16:13] <Daviey> rocking
[16:13] <hggdh> RoAkSoAx: I am starting to think the issue is not with powernap, but with euca itseld
[16:13] <zul> SpamapS: yeah but the cloud tests are pretty extensive compared to the installation/work load tests
[16:13] <RoAkSoAx> hggdh: ok ;)
[16:14] <hggdh> SpamapS: actually we usually start the cloud (read euca, right now) tests with a preseeded ISO install
[16:14] <soren> SpamapS: Yet..
[16:14] <robbiew> SpamapS: right, but it uses images...and it's ourproduct
[16:14] <robbiew> I'm saying, it should be a high priority the week of the milestone, to test the images we put out...iso or cloud
[16:15] <Daviey> soren, you are just trying to create more work for us! :)
[16:15] <soren> Daviey: Quite the contrary.
[16:15] <soren> Daviey: The biggest problem I had with automated iso testing was lack of resources.
[16:15] <soren> Computing resources, that is.
[16:15] <Daviey> ack
[16:16] <hggdh> double-ack
[16:16] <soren> If I could get a cloud to run the ISO for me, hooking up VNC to a screen scraping thing would be relatively easy.
[16:16] <SpamapS> Alright.. so the signal to iso test should be... the alpha freezes?
[16:16] <ttx> SpamapS: it's actually the candidate generation
[16:16] <hggdh> I do not agree
[16:16] <hggdh> we should run them daily
[16:17] <ttx> SpamapS: otherwise you don't have a page to record results on iso.qa.u.c
[16:17] <Daviey> hggdh, i think we are talking manual
[16:17] <SpamapS> yes, talking about manual testing
[16:17] <Daviey> in my mind.. automated complements manual
[16:17] <SpamapS> ttx: right, I don't get any emails when that happens.
[16:17] <Daviey> I imagine most people tried the candidate iso before release, right?
[16:17] <SpamapS> despite being subscribed to all the iso tests I usually do
[16:18] <robbiew> SpamapS: but you get the freeze notice right?
[16:18] <SpamapS> robbiew: yes
[16:18] <Daviey> SpamapS, that is a good point... the current way of tracking the candidates is via  watching -release...and that is a process which is broken
[16:19] <robbiew> hmm
[16:19] <robbiew> skaet: around?
[16:19]  * SpamapS gives in and just subscribes to every list on lists.ubuntu.com
[16:19] <robbiew> so I can see about getting an email notification sent out when the isos are ready to test
[16:20] <Daviey> SpamapS, that isn't enough :)
[16:20] <JamesPage> So what do we need in terms of notifications?
[16:20] <Daviey> Subject: Candidate posted
[16:21] <Daviey> Subject: Re-rolled... because XYZ.
[16:21] <smoser> I really dont think its that hard.
[16:21] <hggdh> where? which list?
[16:21] <smoser> The week of a release, you need to be testing
[16:21] <smoser> we need to get through all the tests on iso tracker
[16:21] <smoser> you really should not need a reminder for release week
[16:21] <Daviey> smoser, last cycle i wasted time testing a stale candidate..
[16:21] <robbiew> ack
[16:21] <SpamapS> well how do people know they've appeared now?
[16:21] <Daviey> this needs better co-ordination.
[16:21] <robbiew> #ubuntu-release
[16:21] <robbiew> it's a great channel
[16:22] <robbiew> I highly recommend it during the release
[16:22] <robbiew> lol
[16:22] <Daviey> heh
[16:22] <SpamapS> smoser: This is the first I've heard of this. The maverick cycle, a little man would pop up in my IRC window and say "test the isos now" ...
[16:22] <robbiew> I'll take a todo on getting a notification sent out
[16:22] <Daviey> reading scrollback seems to be a less clean process IMO.
[16:22] <JamesPage> [ACTION] robbiew to ensure notifications of release candidates (and re-rolls) sent out
[16:22] <MootBot> ACTION received:  robbiew to ensure notifications of release candidates (and re-rolls) sent out
[16:23] <JamesPage> OK so is the combination of watching #ubuntu-release and some extra notifications going todo the trick?
[16:23] <robbiew> it better
[16:23] <SpamapS> Apologies for being naive above it. I just want to know when I should start focusing on testing the iso vs. other things.
[16:23] <robbiew> we do have schedule
[16:23] <robbiew> it's not like the release should creep up on anyone by surprise ;)
[16:24] <robbiew> SpamapS understood, and I think you raise a good pointr
[16:24] <robbiew> point
[16:24]  * JamesPage agrees with SpamapS
[16:24] <robbiew> the release team should at least fire off a notice when ISOs are good to test
[16:24] <zul> you should have it the back of your mind that we are releasing on this date and see what needs to be done
[16:25]  * kirkland wonders if Ubuntu should have a desktop indicator for that sort of thing ;-)
[16:25] <ttx> what we did during maverick is have a "release contact" in the team (was me) whose job it was to remind people to switch to ISO testing (and talked about it in weekly meetings). A bit inefficient, but worked
[16:25] <SpamapS> zul: +1 for that.. I have just now added iso testing to my calendar in line with the release calendar.
[16:25] <kirkland> perhaps TestDrive could provide one
[16:25] <Daviey> kirkland, byobu indicator!
[16:25] <kirkland> if you have TestDrive installed, it puts a message in the indicator
[16:25] <hggdh> +1
[16:25] <RoAkSoAx> yeah we could do that
[16:25] <JamesPage> I think we are missing the point of this meeting - surely we should be discussing activity over the next week in the 'Natty development' section?
[16:25] <kirkland> A1/A2/A3/B1/RC/GA Candidate Available
[16:26] <SpamapS> Hah.. and of course.. the week before Alpha 3 is the ensemble sprint. :P
[16:26] <Daviey> ttx, I had an advantage of seeing what was going on by being on the same TZ as you... i think that helped me.
[16:26] <SpamapS> JamesPage: true.. I think zul had something he wanted to bring up regarding Natty development.
[16:27] <zul> i thought that was the next topic
[16:27] <zul> if we are done with natty release stuff
[16:27] <JamesPage> zul: as our rep in the release meeting can you highlight any key activities over the next week just in case its slipped someones mind?
[16:28] <SpamapS> Indeed.. though before that was "events" ..which seems to have been wiped away.
[16:28] <zul> JamesPage: i think i can do that
[16:28] <JamesPage> zul: excellent - I'll make is standing agenda
[16:28] <JamesPage> OK so moving on.
[16:28] <robbiew> kirkland: +1 on the testdrive idea
[16:28] <JamesPage> [TOPIC] Ubuntu Server Team Events
[16:28] <MootBot> New Topic:  Ubuntu Server Team Events
[16:29] <Daviey> JamesPage and I had a good weekend at foSdem ... report to follow
[16:29] <SpamapS> I added this last week..
[16:29] <SpamapS> just to highlight when and where Ubuntu Server interested people will be.
[16:29] <JamesPage> SpamapS: I'll copy in the forward plan from last weeks agenda - we can just update as and when.
[16:30] <ttx> I'll be at UKUUG Spring Conference in Leeds in March, talking OpenStack (and Ubuntu Server)
[16:30] <SpamapS> well its ok.. just wanted to mention that Dustin and I will be at SCALE9x Feb 25 .. and Dustin is speaking I think on Feb 26
[16:30] <JamesPage> Scale9x at the end of the month - ClintByrum (SpamapS) and DustinKirkland (kirkland) attending
[16:31] <kirkland> SpamapS: JamesPage: yup!
[16:31] <JamesPage> ttx: I'll add that to the list
[16:31] <ttx> JamesPage: cool!
[16:31] <JamesPage> Anything else for events?
[16:31] <SpamapS> kirkland: unfortunately I have to leave Fri night but I'll be there all day Friday.
[16:32] <JamesPage> [TOPIC] Mysql 5.5 for Natty (zul)
[16:32] <MootBot> New Topic:  Mysql 5.5 for Natty (zul)
[16:32] <JamesPage> over to you zul
[16:32] <zul> hi yeah...
[16:32] <Daviey> :0
[16:32] <zul> i wanted to throw out the idea of pushing mysql 5.5 to natty
[16:32] <SpamapS> +1 from me
[16:32] <zul> as a replacement for mysql 5.1
[16:32] <SpamapS> its faster
[16:32] <SpamapS> and the GA release
[16:33] <SpamapS> and does not introduce any significant incompatible changes w/ 5.1
[16:33] <zul> amazon is using it for their images
[16:33] <JamesPage> How long has the GA been about?
[16:33] <zul> but there might be some changes with libmysqlclient we might have to worry about
[16:33] <SpamapS> since early December
[16:33] <SpamapS> zul: the license changes seem to have been accidental
[16:34] <Daviey> it makes sense for natty to have the latest
[16:34] <SpamapS> zul: and actually happened in 5.1
[16:34] <JamesPage> any point releases since then?
[16:34] <zul> SpamapS: im talking about rebulding things like php open office etc etc
[16:34] <SpamapS> JamesPage: no. I know what you're thinking.. in the past mysql's first GA was bad.. but 5.1 and 5.5's first GA's seem to have fixed that problem with wider testing.
[16:34] <SpamapS> zul: oh, AFAICT, libmysqlclient did not change ABI or API
[16:35] <zul> SpamapS: sure but we are going to have to test it first ;)
[16:35] <SpamapS> And IMO its ok to have the client libs coming from 5.1
[16:35] <zul> so thoughts?
[16:35]  * Daviey suggests "do it"
[16:36] <Daviey> if there are serious concerns... PPA it and we can sniff test
[16:36] <zul> also ill mention that debian will probably be going to 5.5 as well (a feeling)
[16:36] <Daviey> post to ubuntu-devel suggesting people test from Desktop apps etc.
[16:36] <SpamapS> https://launchpad.net/~clint-fewbar/+archive/fixes has the initial packages
[16:36] <zul> Daviey: ack
[16:36] <JamesPage> Is this someone we can decide in this meeting or does it need discussion on ubuntu-devel?
[16:37] <zul> and they have been reviewed by the debian mysql maintainer
[16:37] <zul> i think it needs more discussion in ubuntu-devel because there is alot of packages that need libmysqlclient
[16:37] <SpamapS> right now, the mysql-5.5 packages I did don't even build libmysqlclient
[16:38] <JamesPage> OK so it feel like the consensus here is to go for it; but it needs broader discussion prior to committing in Natty
[16:38] <Daviey> yup.
[16:38] <JamesPage> We are only a few weeks off feature freeze so this needs to happen quite quickly
[16:38] <JamesPage> zul: you OK for an action to email ubuntu-devel asap?
[16:38] <SpamapS> yeah seems useful to just send to ubuntu-devel to get ack/nack's from interested parties
[16:38] <zul> JamesPage: yep
[16:39] <Daviey> once the version is in... we can ignore feature freeze, as it will be bug fixes :)
[16:39] <JamesPage> [ACTION] zul - Email ubuntu-devel to gather consensus on whether MySQL 5.5 should be included for Natty.
[16:39] <MootBot> ACTION received:  zul - Email ubuntu-devel to gather consensus on whether MySQL 5.5 should be included for Natty.
[16:39] <JamesPage> next....
[16:39] <JamesPage> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[16:39] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[16:39] <JamesPage> hggdh: all yours
[16:40] <hggdh> OK. We are behind on UEC (known, buyt anyway); ISO testing on Hudson seens to be OK now, wioth the two servers I dedicated to it
[16:40] <hggdh> and with James' change to run multiple jobs
[16:41] <Daviey> hggdh, ahh..  i still need to update my hudson cnode.
[16:41] <hggdh> but I felt sort of alone on this testing...
[16:41] <JamesPage> hggdh: is that why each test it taking longer to run now?
[16:42] <hggdh> JamesPage: probably, contention on I/O, I would say. Also, I am still to hadd a check for a critical error on d-i
[16:42] <hggdh> Sunday and Monday we spent 40 min waiting for the timeout to pop on a d-i error on the first 5 min
[16:42] <zul> hggdh: we you able to reproduce that samba bug you were telling me about?
[16:43] <hggdh> zul: on the Hudson test -- I figured it out, we need to manually logon the first time as an user for the smb userId to be generated
[16:44] <zul> hggdh: right
[16:44] <hggdh> so _this_ test will have to be changed
[16:44] <hggdh> also, I need a position on how large should be the minimal install
[16:44] <JamesPage> hggdh: its grown since the last release....
[16:44] <hggdh> yes. To what? ;-)
[16:45] <Daviey> hggdh, 4 GB sparse?
[16:45] <Daviey> heck 100GB sparse? :)
[16:45] <hggdh> Daviey: no, the JeOS install (f4 on d-i, minimal Ubuntu system
[16:46] <Daviey> oh
[16:46] <JamesPage> hggdh: I think the original test was 550MB - I allowed +25MB for the testing overlay and its over that as well at the moment.
[16:46] <hggdh> JamesPage: yes. But I remember seeing 500M, not 550M
[16:47] <hggdh> (not on the test, in the QA docs)
[16:47] <JamesPage> You might be right; lets take this offline and double check
[16:47] <hggdh> roj
[16:47] <hggdh> and I am done
[16:47] <JamesPage> [ACTION] hggdh JamesPage to check sizing for minimal installation for QA purposes
[16:47] <MootBot> ACTION received:  hggdh JamesPage to check sizing for minimal installation for QA purposes
[16:47] <JamesPage> [TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)
[16:47] <MootBot> New Topic:  Weekly Updates & Questions for the Documentation Team (sommer)
[16:48] <JamesPage> sommer: here this week?
[16:48] <SpamapS> I emailed sommer..
[16:48] <SpamapS> he's super busy with the new job
[16:48] <SpamapS> and sent apologies if he wasn't able to make it
[16:48] <Daviey> yeah.. i don't think things will change,.... had the same experience a few weeks ago.
[16:48] <SpamapS> Promises to work on the server guide again soon... and said he would appreciate help with some of the bugs already reported on it.
[16:49] <Daviey> We might need to refine  how we are tracking docs
[16:49] <Daviey> I've done no docs for natty yet.
[16:49] <Daviey> has anyone else?
[16:49] <SpamapS> Upstart docs has been a running theme for me.
[16:50] <robbiew> yeah...I think we need a hard push for updated docs at UDS
[16:50] <SpamapS> But they're not done in any official capacity yet.. I've saved a lot of that work for A3 and beta.
[16:50] <robbiew> at least by 12.04LTS
[16:50]  * robbiew needs to get folks excited about it...if that's even possible :/
[16:50] <JamesPage> It's not a key focus for this cycle then?
[16:50] <robbiew> yay for docs!
[16:50] <robbiew> lol
[16:50] <robbiew> well...we should have it every cycle
[16:50] <robbiew> but given the LTS is where we see most of our use
[16:50] <RoAkSoAx> I'm gonna write Clustering docs post alpha3
[16:50] <hallyn> hm, i'd assumed they were 'taken care of', so i'll go ahead and take a look
[16:51] <SpamapS> sommer's been taking such good care of us we haven't had to do much.
[16:51] <hallyn> @sommer++ for babying us
[16:51] <robbiew> right...but we should be making sure it's correct
[16:51] <robbiew> as we change things...and he may not catch it
[16:51] <Daviey> yup
[16:51]  * JamesPage realises that he's missed the kernel team out this week.
[16:52] <Daviey> poor kernel team
[16:52]  * smb was already thinking he missed it
[16:52] <JamesPage> so moving on from docs for this week.
[16:52] <JamesPage> [TOPIC
[16:52] <JamesPage> [TOPIC] Weekly Updates & Questions for the Kernel Team (smb)
[16:52] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (smb)
[16:52] <JamesPage> smb: over to you
[16:52] <smb> Just wanted to bring up two things I am on
[16:52] <smb>  * Continue to work through the SUSE Xen patchset and backport changes that
[16:52] <smb>    came through upstream stable but missed Xen clones of files (Lucid-ec2).
[16:52] <smb>    Done in the hope to get a fix for bug 708920 in the process. For the future
[16:52] <smb>    I need to think of how to prevent that skew in the first place.
[16:52] <smb>  * For bug 709414: check testcase with Natty client to see whether the result
[16:52] <smb>    is still the same. Both Lucid and Natty do unstable writes followed
[16:52] <smb>    immediately with a commit request which syncs. So it seems to be sync but
[16:52] <smb>    not very efficiently. Opened an upstream bug to see what those guys think.
[16:53] <smb> Otherwise open to questions.
[16:53] <robbiew> smb: so I thought it worked in Natty, but not in Lucid (regarding the NFS bug)
[16:53] <smb> robbiew, Well to me it looked identical
[16:54] <robbiew> smb: right, surbhi said the same thing, but I believe in actual testing, the behaviour is different....but I could be wrong
[16:54] <smb> At least when I looked at the output doing test with a lucid and natty client
[16:54] <robbiew> ah
[16:54] <robbiew> I'll yield to you for sure ;)
[16:54] <smoser> smb, mostly out of curiousity, i'd like to have you read bug 710319
[16:55] <smb> I think Surbhi said something about a difference probably in the code but I am more practical there
[16:55] <smoser> it seems that an upstream bug that *should* be fixed (per commits reported to fix it) still exists in lucid.
[16:55] <smb> smoser, What release is that for
[16:55] <robbiew> for reference the public bug for 709414 is bug 709392
[16:55] <smb> I think we may still need a second half for Maverik
[16:56] <smoser> i have not reproduced on natty but i'm not certain the test case is guaranteed reproduce.
[16:56] <smoser> there is an easy test case there though, that fails for me on lucid, does not fail on natty.
[16:56] <smoser> (but they're 2 different systems i'm testing on)
[16:57] <SpamapS> 3 minutes
[16:57] <smb> smoser, Actually Lucid may also yield wrong load output
[16:57] <smb> That would be fixed in Natty
[16:57] <JamesPage> SpamapS: noted
[16:58] <JamesPage> Anything else for smb?
[16:58] <smb> smoser, I think I have done either test kernels or at least prepared them for lucid but lacking a reporducer/reporter did not continue
[16:59] <JamesPage> [TOPIC] Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[16:59] <MootBot> New Topic:  Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[16:59] <smoser> we can talk offline, smb, but for me, on lucid, the test case pointed to fails.  ie, time can go backwards for utime.
[16:59] <JamesPage> kim0: anything from the community team this week?
[16:59] <smoser> (and others verify that)
[16:59] <smb> smoser, Yep lets take this offline
[17:00]  * Daviey wonders if kim0 has internet access this week
[17:00] <ttx> Question for community or team: on https://launchpad.net/sprints/uds-o UDS is marked as starting Monday afternoon and ending Friday noon. Is that the plan ?
[17:00] <Daviey> ttx, i suspect it's a TZ mistake
[17:00] <bjf> JamesPage, your running late
[17:01] <ttx> Daviey: it's more than a TZ mistake. It makes it 4 days total
[17:01] <Daviey> jcastro, ?
[17:01] <Daviey> ttx, 00:00 vs 12:00?
[17:01] <JamesPage> [TOPIC] Announce next meeting date and time
[17:01] <MootBot> New Topic:  Announce next meeting date and time
[17:01] <JamesPage> Tuesday, February 15 2011 16:00 UTC
[17:01] <jcastro> timezone problem, I'll fix it, sorry guys
[17:02] <Daviey> ttx, if jcastro doesn't respond.. i'll find out and get back to you.
[17:02] <ttx> jcastro: cool, thanks
[17:02] <maco> Daviey: he just did
[17:02] <JamesPage> bjf: all yours....
[17:02] <Daviey> heh
[17:02] <JamesPage> #endmeeting
[17:02] <MootBot> Meeting finished at 11:02.
[17:02] <bjf> #startmeeting
[17:02] <MootBot> Meeting started at 11:02. The chair is bjf.
[17:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:02] <SpamapS> JamesPage: good meeting! thanks!
[17:02] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:02] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[17:02] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[17:02] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[17:02] <bjf> # Meeting Etiquate
[17:02] <bjf> #
[17:02] <bjf> # NOTE: '..' indicates that you are finished with your input.
[17:02] <bjf> #
[17:02] <bjf> [TOPIC] ARM Status (bjf)
[17:02] <MootBot> New Topic:  ARM Status (bjf)
[17:03] <bjf> Nothing new, do we have ARM folks anymore ?
[17:03] <bjf> ..
[17:03] <sconklin> snort
[17:03] <bjf> [TOPIC] Release Metrics (JFo)
[17:03] <MootBot> New Topic:  Release Metrics (JFo)
[17:03] <JFo> Release Meeting Bugs (9 bugs, 12 Blueprints)
[17:03] <JFo> [17:03] <JFo>  * 2 linux kernel bugs (up 1)
[17:03] <JFo>  * 0 linux-ti-omap bugs (no change)
[17:03] <JFo>  * 0 linux-meta-ti-omap bug (no change)
[17:03] <JFo> [17:03] <JFo>  * 21 linux kernel bugs (up 4)
[17:03] <JFo>  * 0 linux-ti-omap bugs (no change)
[17:03] <JFo>  * 0 linux-meta-ti-omap bug (no change)
[17:03] <JFo> [17:03] <JFo>  * 7 blueprints (Including HWE Blueprints)
[17:03] <JFo> [17:03] <JFo>  * 55 Linux Bugs (no change)
[17:03] <JFo> [17:03] <JFo>  * 91 Linux Bugs (no change)
[17:03] <JFo> [17:03] <JFo>  * [[https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on | Bugs with Patches]]
[17:03] <JFo>  * [[http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/ | Breakdown by status]]
[17:04] <JFo> ..
[17:04] <bjf> [TOPIC] Blueprints: Natty Bug Handling (JFo)
[17:04] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-bug-handling
[17:04] <MootBot> New Topic:  Blueprints: Natty Bug Handling (JFo)
[17:04] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-bug-handling
[17:04] <JFo> * found a logic error (what I believe to be one at least) in the process-new arsenal script.
[17:04] <JFo> Working to nail down the behavior in that script so that it can be addressed.
[17:04] <JFo> * I am cleaning up my notes about kernel testing and should have updates to the wiki documentation done this week.
[17:04] <JFo> ..
[17:04] <bjf> [TOPIC] Blueprints: Enhancements to the firmware test suite (cking)
[17:04] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
[17:04] <MootBot> New Topic:  Blueprints: Enhancements to the firmware test suite (cking)
[17:04] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-firmware-test-suite-enhancements
[17:04] <cking> Changes to fwts (natty development branch):
[17:04] <cking>  * add oops checker
[17:04] <cking>  * fix double free in dmar test
[17:04] <cking>  * improving option handling
[17:04] <cking> ..
[17:05] <bjf> [TOPIC] Blueprints: Review of the Stable Maintenance Process (sconklin / bjf)
[17:05] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review
[17:05] <MootBot> New Topic:  Blueprints: Review of the Stable Maintenance Process (sconklin / bjf)
[17:05] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-stable-process-review
[17:05] <sconklin> || The kernel Stable team has had kernels in -proposed for almost
[17:05] <sconklin> || a week, and a number of the associated fixes have been verified.
[17:05] <sconklin> ||
[17:05] <sconklin> || Due to the alpha release of Natty and the .2 release of Lucid
[17:05] <sconklin> || and the demand on certification and QA resources, there is
[17:05] <sconklin> || time for us to spin another release and put it in -proposed.
[17:05] <sconklin> || Fixes verified already in the current -proposed kernel will
[17:05] <sconklin> || remain verified, and any new fixes will require verification.
[17:05] <sconklin> ||
[17:05] <sconklin> || We expect to produce those kernels this week.
[17:05] <sconklin> ||
[17:05] <sconklin> || The process continues to get refined as we go through new
[17:05] <sconklin> || cycles. We have taken responsibility for updating the
[17:05] <sconklin> || verification tags on bugs and are changing our tools to
[17:05] <sconklin> || deal with that. We also are developing internal tools to
[17:05] <sconklin> || help track package versions and alert us to errors such
[17:05] <sconklin> || as not having an updated meta package when an ABI bump
[17:05] <sconklin> || has occurred.
[17:05] <sconklin> ||
[17:05] <sconklin> ..
[17:06] <bjf> [TOPIC] Status: Cert. Team  (ara)
[17:06] <MootBot> New Topic:  Status: Cert. Team  (ara)
[17:06] <ara> Nothing to report on SRUs. We won't be testing -proposed kernels this week or the following one.
[17:06] <ara> ..
[17:06] <bjf> [TOPIC] Status: Ecryptfs (jj)
[17:06] <MootBot> New Topic:  Status: Ecryptfs (jj)
[17:07] <jjohansen> - second revision with cleanups and bug fixes pushed to ecryptfs mailing list
[17:07] <jjohansen> - revising description text with kirklands feedback for fsdevel submit
[17:07] <jjohansen> - tyhicks has been busy and unable to review, is planning to review today
[17:07] <jjohansen> - may alter shortname generation to use directory ino pending discussion
[17:07] <jjohansen> - may convert from trusted to user. xattr namespace pending discussion
[17:07] <jjohansen> ..
[17:08] <bjf> [TOPIC] Status: Natty (apw)
[17:08] <MootBot> New Topic:  Status: Natty (apw)
[17:08] <apw> The natty-alpha-2 kernel seems to be holding up ok.  Since the freeze lifted we have uploaded v2.6.38-2.29 (v2.6.38-rc3) based kernel.  This has brought another swathe of DRM fixes, though things are still iffy there.  v2.6.38-rc4 has just released and will be uploaded shortly.
[17:08] <apw> Overall we are looking good on longer term tasks with most of the key deliverables complete.  We are now tracking mainline and fielding issues as they appear.
[17:08] <apw> ..
[17:08] <bjf> [TOPIC] Security & bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper (sconklin / bjf)
[17:08] <MootBot> New Topic:  Security & bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper (sconklin / bjf)
[17:08] <sconklin> || Package                                    || Kernel PPA          || Proposed             || Upd/Sec              ||  TiP || Verified ||
[17:08] <sconklin> ||                                            ||                     ||                      ||                      ||      ||          ||
[17:08] <sconklin> || dapper   linux-source-2.6.15               || 2.6.15-55.92        ||                      || 2.6.15-55.91         ||      ||          ||
[17:08] <sconklin> || ---      linux-meta                        ||                     ||                      || 2.6.15.56            ||      ||          ||
[17:08] <sconklin> || ---      linux-backports-modules-2.6       ||                     ||                      || 2.6.15-55.13         ||      ||          ||
[17:09] <sconklin> ||                                            ||                     ||                      ||                      ||      ||          ||
[17:09] <sconklin> || hardy    linux                             || 2.6.24-28.85        || 2.6.24-28.84         || 2.6.24-28.81         ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-meta                        ||                     ||                      || 2.6.24.28.30         ||      ||          ||
[17:09] <sconklin> || ---      linux-restricted-modules-2.6.24   ||                     ||                      || 2.6.24.18-28.7       ||      ||          ||
[17:09] <sconklin> || ---      linux-ubuntu-modules-2.6.24       ||                     ||                      || 2.6.24-28.47         ||      ||          ||
[17:09] <sconklin> ||                                            ||                     ||                      ||                      ||      ||          ||
[17:09] <sconklin> || karmic   linux                             || 2.6.31-22.72        || 2.6.31-22.71         || 2.6.31-22.70         ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-meta                        ||                     ||                      || 2.6.31.22.35         ||      ||          ||
[17:09] <sconklin> || ---      linux-ports-meta                  ||                     ||                      || 2.6.31.22.18         ||      ||          ||
[17:09] <sconklin> || ---      linux-backports-modules-2.6.31    ||                     ||                      || 2.6.31-22.24         ||      ||          ||
[17:09] <sconklin> || ---      linux-ec2                         || 2.6.31-307.25       || 2.6.31-307.24        || 2.6.31-307.23        ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-meta-ec2                    ||                     ||                      || 2.6.31.307.6         ||      ||          ||
[17:09] <sconklin> || ---      linux-fsl-imx51                   || 2.6.31-112.30       ||                      || 2.6.31-112.28        ||      ||          ||
[17:09] <sconklin> || ---      linux-meta-fsl-imx51              ||                     ||                      || 2.6.31.112.10        ||      ||          ||
[17:09] <sconklin> || ---      linux-mvl-dove                    ||                     ||                      || 2.6.31-214.32        ||      ||          ||
[17:09] <sconklin> || ---      linux-meta-mvl-dove               ||                     ||                      || 2.6.31.214.13        ||      ||          ||
[17:09] <sconklin> ||                                            ||                     ||                      ||                      ||      ||          ||
[17:09] <sconklin> || lucid    linux                             || 2.6.32-29.57        || 2.6.32-29.57         || 2.6.32-28.55         ||    6 ||        1 ||
[17:09] <sconklin> || ---      linux-backports-modules-2.6.32    || 2.6.32-29.28        || 2.6.32-29.28         || 2.6.32-28.27         ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-meta                        || 2.6.32.29.34        || 2.6.32.29.34         || 2.6.32.28.32         ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-ec2                         || 2.6.32-313.25       || 2.6.32-313.25        || 2.6.32-312.24        ||    8 ||        1 ||
[17:09] <sconklin> || ---      linux-meta-ec2                    || 2.6.32.313.14       || 2.6.32.313.14        || 2.6.32.312.13        ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-ports-meta                  || 2.6.32.29.22        || 2.6.32.29.22         || 2.6.32.28.21         ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-lts-backport-maverick       || 2.6.35-25.44~lucid1 || 2.6.35-25.44~lucid1  || 2.6.35-23.41~lucid1  ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-meta-lts-backport-maverick  ||                     ||                      || 2.6.35.23.35         ||      ||          ||
[17:09] <sconklin> || ---      linux-fsl-imx51                   || 2.6.31-608.22       ||                      || 2.6.31-608.20        ||      ||          ||
[17:09] <sconklin> || ---      linux-mvl-dove                    || 2.6.32-214.30       || 2.6.32-214.30        || 2.6.32-211.27        ||    6 ||        1 ||
[17:09] <sconklin> || ---      linux-meta-mvl-dove               || 2.6.32-214.15       || 2.6.32.214.15        || 2.6.32.209.12        ||    0 ||        0 ||
[17:09] <sconklin> ||                                            ||                     ||                      ||                      ||      ||          ||
[17:09] <sconklin> || maverick linux                             || 2.6.35-26.46        || 2.6.35-26.46         || 2.6.35-25.44         ||    9 ||        9 ||
[17:09] <sconklin> || ---      linux-backports-modules-2.6.35    || 2.6.35-26.17        ||                      || 2.6.35-25.16         ||      ||          ||
[17:09] <sconklin> || ---      linux-meta                        || 2.6.35.26.33        || 2.6.35.26.33         || 2.6.35.25.32         ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-ports-meta                  || 2.6.35.26.20        || 2.6.35.26.20         || 2.6.35.25.19         ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-mvl-dove                    ||                     || 2.6.32-414.30        ||                      ||    3 ||        3 ||
[17:09] <sconklin> || ---      linux-meta-mvl-dove               ||                     || 2.6.32.414.4         ||                      ||    0 ||        0 ||
[17:09] <sconklin> || ---      linux-ti-omap4                    ||                     ||                      || 2.6.35-903.14        ||      ||          ||
[17:09] <sconklin> || ---      linux-meta-ti-omap4               ||                     ||                      || 2.6.35-903.6         ||      ||          ||
[17:09] <sconklin> ||                                            ||                     ||                      ||                      ||      ||          ||
[17:10] <sconklin> || Package                                    || Kernel PPA          || Proposed             || Upd/Sec              ||  TiP || Verified ||
[17:10] <sconklin> ..
[17:11] <bjf> [TOPIC] Incoming Bugs: Regressions (JFo)
[17:11] <MootBot> New Topic:  Incoming Bugs: Regressions (JFo)
[17:11] <JFo> Incoming Bugs
[17:11] <JFo>  149 Natty Bugs (up 41)
[17:11] <JFo>  1141 Maverick Bugs (up 8)
[17:11] <JFo>  1005 Lucid Bugs (up 8)
[17:11] <JFo> Current regression stats (broken down by release):
[17:11] <JFo> [17:11] <JFo>   * 35 maverick bugs (up 3)
[17:11] <JFo>   * 75 lucid bugs (no change)
[17:11] <JFo>   * 6 karmic bugs (no change)
[17:11] <JFo>   * 0 hardy bugs (no change)
[17:11] <JFo> [17:11] <JFo>   * 220 maverick bugs (down 1)
[17:11] <JFo>   * 206 lucid bugs (up 2)
[17:11] <JFo>   * 38 karmic bugs (no change)
[17:11] <JFo>   * 2 hardy bugs (no change)
[17:11] <JFo> [17:11] <JFo>   * 14 maverick bugs (down 1)
[17:11] <JFo>   * 2 lucid bugs (no change)
[17:11] <JFo>   * 1 karmic bug (no change)
[17:11] <JFo> ..
[17:12] <bjf> [TOPIC] Incoming Bugs: Bug day report (JFo)
[17:12] <MootBot> New Topic:  Incoming Bugs: Bug day report (JFo)
[17:12] <JFo> The  next bug day will be next Tuesday. It will once again cover bugs in the new state.
[17:12] <JFo> I'll put some more information out on what I am interested in solving within these set
[17:12] <JFo> of bugs once I have determined why the process-new script is failing.
[17:12] <JFo> ..
[17:12] <bjf> [TOPIC] Triage Status (JFo)
[17:12] <MootBot> New Topic:  Triage Status (JFo)
[17:12] <JFo> still quite a lot of direct requests to review specific bugs. There are a few people in the community helping out, so that is picking up a bit.
[17:12] <JFo> nothing other than that unless someone else has anything.
[17:12] <JFo> ..
[17:13] <bjf> [TOPIC] Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:13] <MootBot> New Topic:  Open Discussion or Questions: Raise your hand to be recognized (o/)
[17:14] <bjf> thanks everyone
[17:14] <bjf> #endmeeting
[17:14] <MootBot> Meeting finished at 11:14.
[17:14] <JFo> thanks bjf
[17:14] <sconklin> thanks
[17:14] <sforshee> thanks bjf
[19:15] <vish> !away > artir
[23:59] <duanedesign> 'lo all
[23:59] <PabloRubianes> hi