18:00:16 <davej> #startmeeting
18:00:16 <zodbot> Meeting started Fri Jan 20 18:00:16 2012 UTC.  The chair is davej. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:28 <davej> #meetingname kernel
18:00:28 <zodbot> The meeting name has been set to 'kernel'
18:00:58 <jwb> LET'S DO THIS
18:01:12 <davej> \o/
18:02:24 <davej> lets start as always with a runthrough of the releases.
18:02:40 <jwb> k
18:02:53 <davej> for the most part, we can do 15/16 as the same thing (aside from the rebase which I'll cover later)
18:03:41 <jwb> so f15 and f16 are on 3.1.10 at the moment
18:03:55 <jwb> with a number of additional security patches
18:04:12 <jwb> pretty quiet overall the past couple of weeks.  just a few small patches and some stable rebases
18:04:42 <jwb> due to some excellent help at FUDCon, F15 is actually on a somewhat current stable release and not sitting at 2.6.41.4 anymore
18:05:27 <davej> we'll have to keep an eye on the karma situation for updates
18:05:45 <jwb> yeah, agreed.  also do a better job of asking for testing too
18:06:10 <jwb> that mostly covers f15/f16 until last night
18:06:40 <davej> 807 open bugs right now :-/
18:07:15 <jwb> f15 really needs a going-thru for stale bugs at this point
18:07:29 <davej> yeah, though 16 seems to have seen an uptick in bugs lately.
18:07:41 <jwb> a bunch in compat-wireless
18:07:52 <davej> it went from 277 this time last month to 414 today
18:08:09 <jwb> nngh
18:08:16 <davej> we should start keeping stats on the number of wireless bugs we're getting
18:08:30 <davej> because it feels like we're seeing more of them since the compat-wireless thing
18:08:51 <davej> I'll do some bugzilla magic for that later.
18:09:19 <jwb> k
18:09:23 <davej> #action davej to work on bz script to track number of wireless bugs
18:09:51 <jwb> there is still the crazy hibernate issues as well.  a number of bugs seem related to that
18:10:19 <davej> yeah. I'm not sure how that's going to pan out (the 'disable hibernate' bug)
18:10:38 <davej> for sure it would be an unpopular move.
18:10:40 <nirik> it doesn't seem to have too much pushback so far that I have seen.
18:10:47 <jwb> adamw offered to do an informal poll on the forums.  while i hate forums for other reasons, it might be worth doing...
18:10:50 <davej> nirik: I think it's mostly off peoples radar so far
18:10:53 <jwb> nirik, it hasn't really been broadcsat must
18:10:55 <jwb> er, much
18:10:56 <nirik> could be.
18:11:21 <nirik> was there a chance of a 'please-let-me-hibernate' boot time option?
18:11:42 <davej> that doesn't really solve anything, because when people using it get fs corruption, we're where we are now.
18:12:33 <adamw> yeah, that doesn't make sense to me
18:12:37 <adamw> either we kill it entirely or not at all
18:13:07 <nirik> well, much fewer people will see or use it.
18:13:14 <nirik> but ok
18:14:03 <davej> moving on. I committed the f16 rebase to 3.2 last night
18:14:17 <jwb> we could do a username match and only let the hibernate maintainer switch it on, but...
18:14:36 <nirik> davej: running that kernel here, so far everythings fine for me. ;)
18:14:42 <davej> nirik: great
18:14:53 <jwb> i've been running 3.2 for a while.  seems to work well enough here
18:15:04 <davej> yeah, same here.
18:15:34 <brunowolff> Me too.
18:15:38 <davej> jwb: so I'm on vacation next week, how do you want to handle pushing that out ?
18:15:50 <jwb> davej, i'll submit it monday to updates-testing
18:15:58 <davej> that sounds good to me.
18:16:13 <davej> if a 3.2.2 shows up between then, throw that in too.
18:16:19 <jwb> yep
18:16:42 <davej> #action jwb to push 3.2 update to f16-updates-testing on Monday.
18:16:58 <davej> I'll tackle f15 when I get back.
18:17:11 <jwb> i figure we'd let it sit in f16 for a few days after it when to updates stable anyway
18:17:20 <davej> yeah
18:17:35 <jwb> there will be no more 3.1.y updates, so if anything really urgent pops up we'll backport
18:17:44 <jwb> but it'd have to be pretty bad
18:18:11 <davej> this kind of highlights why we need to keep rebasing
18:18:39 <jwb> yeah
18:18:56 <davej> ok, anything else about 15/16 ?
18:19:08 <jwb> don't think so
18:19:46 <davej> ok, so rawhide.
18:20:14 <davej> I went on a spree recently disabling some of the prehistoric crap that we've always built
18:20:51 <davej> there's probably still a load more in there that can go, but it's at least one step closer to being a "modern hardware only" kernel.
18:22:13 <davej> rebase to 3.3rc1 next week ?
18:22:19 <jwb> actually, probably today
18:22:26 <davej> ok
18:22:26 <jwb> i just booted a local build of it
18:22:57 <davej> I've been running it locally the last week or so on my laptop. other than iwlwifi being a disaster, it's been ok
18:23:00 <jwb> the rebase work is done in my local git tree, so i'll probably commit it and do a build with debug disabled later today
18:23:11 <davej> I'm still working that out with the intel guys, who seem to be slowly getting there
18:23:27 <jwb> i have an email i'm sending to the kernel list with a few questions to various people on stuff that came up during the rebase
18:23:33 <jwb> also, yes iwlwifi ugh
18:24:07 <davej> in 3.3, iwlwifi grew some debug options at least, so we should at least be able to debug problems with it easier in the future
18:24:53 <davej> nothing particularly exciting in the 3.3 kernel tbh
18:25:16 <jwb> well, small thing
18:25:29 <jwb> it supposedly has THE fix for the "writes to slow media cripple machine" thing
18:25:31 <davej> I noticed earlier that the 'copy lots of data from dvd kills interactivity' bug seems to be fixed
18:25:35 <davej> hah
18:26:34 <jwb> so aside from hitting a kmemleak issue yesterday that prevented booting (which i have a patch from Catalin for), and a lockdep spew from radeon, it seems to work well enough on my machine
18:27:16 <jwb> davej, for the first build... still disable debug?
18:27:21 <jwb> then build again with it on?
18:27:36 <davej> yeah, sounds like a good idea
18:27:51 <jwb> we said one per rc so even though it makes me nervous i figured we'd stick with our word
18:28:05 <jwb> probably wait until rc1-git1 to turn debug back on anyway (monday)
18:28:20 <davej> I think this will be a good idea just for coverage testing too. sometimes we see bugs that disappear when the debug stuff is turned on
18:28:38 <jwb> yeah, agreed
18:28:41 <jwb> timing related
18:30:33 <davej> ok, running out of material.
18:30:43 <jwb> i think that's about it anyway
18:31:59 <jwb> oh, wait
18:32:02 <jwb> so, utrace
18:32:06 <jwb> it doesn't apply
18:32:34 <jwb> i've left it out of the 3.3-rc1 rebase until oleg can get to it.  seem reasonable?
18:32:40 <davej> yeah
18:32:43 <jwb> word
18:33:18 <davej> hopefully it'll go away for 3.4 (this seems to be a perpetual thing..)
18:33:23 <jwb> heh
18:33:33 <jwb> I'll be sure to CC Oleg in my email to point it out
18:34:13 <davej> at fudcon the systemtap guys seemed optimistic that it was moving in the right direction
18:36:41 <davej> ok, unless anyone else has anything, I guess we can end early
18:36:50 <brunowolff> Are branched and rawhide going to get essentially the same kernel builds?
18:37:05 <jwb> until we hit 3.3 final, probabl
18:37:07 <jwb> y
18:37:14 <brunowolff> Thanks
18:37:16 <jforbes> davej: Anything besides lmbench you want in the performance testing autotest bits?
18:37:53 <davej> brunowolff: yeah, we'll move them forward in lockstep. after 3.3 final, we might keep branched on release builds and rawhide on debug.. ask again later.
18:38:03 <davej> jforbes: ooh, forgot about that stuff
18:38:41 <davej> jforbes: I think that would be a good thing to start with. maybe one of the filesystem benchmarks too (not sure what the benchmark du jour is in that world)
18:38:44 <brunowolff> I haven't seen any updates on adding the extra kernel modules package to the install only list for yum.
18:39:08 <jforbes> davej: yeah, started on the framework yesterday, but still need to figure out a good way to store/graph historic results
18:39:14 <brunowolff> That seems like something that would be nice to have for F17 alpha.
18:39:18 <davej> jforbes: awesome
18:39:54 <davej> jforbes: just to clarify, is this going to be just for performance testing, or also regression testing ?
18:40:15 <jforbes> davej: well, it can be both, though performance was what we talked about
18:40:23 <davej> ok. because the kernel seems to be growing a tests/ dir that might be useful there going forward
18:40:41 <jforbes> davej: so basically when a kernel build test is called, we tell a machine to install, reboot and run the series of tests that we specify
18:41:03 <davej> I wonder if we should perhaps keep a tests/ directory in our git tree.
18:41:13 <jforbes> davej: it would be very easy to add regression testing, or pretty much anything else.
18:41:19 <davej> because I have a boatload of thigns from over the years.
18:41:44 <jforbes> Hmm, git tree would be okay, would be even better if it could end up in an rpm somewhere, so that it is versioned with the kernel we are testing
18:41:58 <jforbes> kernel-tests would be nice :)
18:42:11 <jwb> can we just lump it into kernel-tools?
18:42:19 <davej> possibly.
18:42:19 <jforbes> jwb: sure
18:42:30 <jwb> kernel-everythingelse
18:42:44 <jforbes> Really doesnt matter where it is, just matters that we know how to get it
18:42:45 <davej> though that might grow quite big, whereas someone who just wants perf..
18:42:55 <jwb> davej, perf is split out
18:43:13 <jwb> f16 lumped it into kernel-tools, f17 has it split out again
18:43:16 <davej> oh right, was looking at 16
18:44:33 <davej> ok, I'll take a look at the tests I have sitting around when I come back from vacation, and make a start on organising that
18:44:49 <jforbes> For rawhide, we also have a question of how userspace can interract, but that doesnt have to be decided immediately
18:44:54 <davej> #action davej to look into packaging up kernel test cases
18:46:09 <jforbes> for released versions, we just dont update userspace on the test machine, if only kernel changes, we always know performance differences are a direct result of the kernel
18:46:59 <davej> jforbes: good point. a new glibc for eg could skew results noticably.
18:47:50 <jforbes> davej: right, so for rawhide, I was thinking maybe controlled userspace updates, and we can run pre/post with same kernel to judge impact
18:49:49 <davej> [distracted by arrival of sushi guy]
18:50:36 <jforbes> davej: plenty of time to go over policy once mechanism is finished, doesn't have to be hashed out today
18:50:40 <davej> sure
18:51:17 <davej> lets revisit this in 2 weeks. I'll be back from vacation then, and might have a bunch of new ideas.
18:51:50 <jforbes> excellent
18:52:45 <davej> ok, lets call this done ?
18:52:50 <jwb> yes.
18:53:03 <jsmith> Thanks folks for all your hard work!
18:53:14 <davej> #endmeeting