18:01:34 #startmeeting 18:01:34 Meeting started Fri Nov 11 18:01:34 2011 UTC. The chair is cebbert. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:54 #meetingname fedora-kernel 18:01:54 The meeting name has been set to 'fedora-kernel' 18:03:04 did you have an agenda davej? 18:03:46 http://fpaste.org/xuBm/ is what I've made a note of the last week or so that might need some discussion 18:04:42 ok, the regression thing is all i had in mind 18:05:00 that's probably the quickest to discuss, so shall we do that first? 18:05:11 sure. want me to cover it? 18:05:16 yeah, go ahead 18:05:25 you can forget just turning off rarely-used modules, because i guarantee there are users outhere for everything 18:06:05 so i while i was writing up a blog post about rebasing f15, i had the idea that we should track the number of bugs fixed by a kernel rebase 18:06:16 but davej and i talked about it a bit and that is kind of hard to do 18:06:17 #topic Tracking regressions after kernel rebase 18:06:38 because we'd probably forget to set a keyword in the whiteboard section, or we wouldn't be able to even tell 18:07:02 davej suggested that maybe we should track regressions in rebases instead of fixes 18:07:08 and that seems much more doable 18:07:32 the basic idea is that once we have a regression identified, we make sure to note it in bugzilla 18:07:53 perhaps with 'regression' in the whiteboard field 18:08:06 note the latest working kernel, and the old broken one 18:08:24 and then pass that information to upstream, probably Rafael who I think does the upstream regression tracking 18:08:54 'regression' is an official bugzilla keyword 18:09:08 maybe rebaseregression then ? 18:09:21 yeah, rebaseregression might work. once we settle on 1) if we should do this, and 2) how, i can write up a wiki page 18:09:43 and hopefully we can make it clear enough that triagers can work on this too 18:09:57 so, seem straighforward enough? 18:10:23 seems non-controversial to me. 18:10:50 cebbert, good with 'rebaseregression' and the overall idea? 18:11:10 yeah, sounds good to me 18:11:37 cool. i'll write up a section in the KernelBugTriage page and keep an eye on bugzilla for a while to get this rolling 18:11:52 we'll start it as of the 15 rebase which should go out soonish 18:11:55 #agreed we will use "rebaseregression" in the whiteboard field in bugzilla to track rebase regressions 18:12:02 #action jwb to write up a 'rebase regression' wiki section 18:12:13 tonight with any luck 18:12:32 cebbert, hopefully. not holding my breath 18:12:54 i've been running the 2.6.41.1-rc1 kernel and it seems fine here 18:13:35 yeah. i know jmoyer and a few others are waiting for 3.1.1 in f16 too 18:14:42 reviewing the bazillion patches has been fun 18:15:04 ok, i think that covered the regression stuff 18:15:17 i have just been eyeballing them for sanity since there are too many to really check 18:15:25 davej, given it's a public meeting, do we want to briefly discuss what's going on in each release? 18:15:36 jwb: good idea. 18:16:12 I was actually looking at 14 this morning, and wondering if it's worth pushing out another update. there's that one security bug open, though it's not really a critical one afaict 18:16:13 #topic Status of current and pending releases 18:16:28 the "oom killer fires when it shouldn't" bug. 18:16:46 davej, there's an nfs one that was just opened, but i haven't reviewed it yet to see if it's in f14 18:16:51 i don't think that will happen in f14 18:16:53 at this point, I'm leaning towards saying the fix is to update to 15 or 16 18:17:04 sounds fine 18:17:09 we have all the fixes but one small locking one for the CVE 18:17:29 i'm in the middle of upgrading my last f14 machine to f16 anyway, so i no longer have an easy test platform 18:18:16 so yeah, 14. kind of a disaster, but we get to forget about it in less than a month. 18:18:38 will be interesting to see how many of the 200 or so bugs stay open when we move them to 15/16 18:20:39 F15 and F16 will be getting 3.1.1 soon 18:21:03 do we assume F17 will get 3.3? 18:21:09 linville also backported the 3.2-rc1 brcm80211 drivers to f15/f16 18:21:18 which should make a number of people happy 18:21:43 cebbert, i'm guessing f17 will be 3.3, unless we have a massively long release again 18:21:44 cebbert: that sounds like a fair estimate, assuming nothing crazy happens. 18:23:00 3.2 has been pretty good thus far 18:23:18 especially considering how much stuff went into the merge window because of kernel.org being down 18:24:06 I've not noticed anything crazy going in that will cause us concern. 18:24:27 though I miss the commits mailing list, which is how I used to review stuff. 18:25:56 what happened to the stable list, did it get abolished too? 18:25:56 commits list? 18:26:10 cebbert, no. it got moved to stable@vger.kernel.org 18:26:43 jwb: yeah there was a list that every commit went to 18:27:54 http://www.kernel.org/hg/linux-2.6 seems to be gone forever too, though the url still tries to do something 18:27:57 davej, er... our commits or upstream? 18:28:01 upstream 18:28:09 davej, oh, ok. 18:28:45 cebbert, matt mackall just sent a reply to lkml about that 18:28:45 i used to pull everything into mercurial because it has sane ordering of the commits when you use its webserver 18:29:05 i guess he's going to move the hg repo elsewhere 18:29:18 oh good 18:30:21 anything else on the releases? 18:30:32 I got nothing. 18:32:02 so, on to the separate package for rarely-used modules? 18:32:11 yep 18:32:35 cebbert, so you don't think the 'turn off, re-enable' approach is going to work? 18:32:36 #topic Separate package for rarely-used modules 18:32:43 jwb: no way 18:32:54 aww... i liked that better 18:33:07 i know for certain that people are using the rose protocol, for example 18:33:18 well.. there is the question of if we're enabling something for one guy, is that worth it ? 18:33:42 also, if that guy is using something like that is he able to rebuild his own kernel? 18:33:46 etc 18:34:17 the problem is that you can't tell from bugzilla reports how many actual users there are 18:34:37 i can tell there's a bunch of irritated alps touchpad users... 18:34:38 ;) 18:34:43 and i guess smolt doesn't collect the full module list? 18:34:56 oh, smolt 18:35:05 there was talk of making that useful 18:35:47 let's come back to smolt at the end if there is time 18:36:00 some of the stuff we enable seems a bit.. far out. take for example CAN. The idea of someone using fedora for that sort of thing is kind of terrifying. 18:36:25 yeah 18:36:26 I hope to god no-one is running medical applications or factory control systems on fedora. 18:36:27 i'd bet you that there are quite a few users of that 18:37:01 people prototyping new control systems will be using fedora 18:37:09 davej, i guess on the flip side, how many bug reports are we getting against CAN? 18:37:14 which afaik is 0 18:37:18 jwb: well it's had a few CVEs 18:37:23 ah, point 18:37:30 yeah 18:37:40 all of these lesser used protocols are pretty awful, mostly because of the limited testing they get 18:37:54 like infiniband? 18:38:00 ;) 18:38:13 heh 18:38:14 we should really consider making >1 subpackage too 18:38:48 as long as we don't go too fine-grained. 18:38:55 cebbert, what do you mean? 18:39:07 it scares me when i look at the specfile though 18:39:08 if we're only doing this for a dozen modules, I don't think there's a lot of point 18:39:22 i have no problems messing around in the spec file 18:39:32 jwb: maybe one for drivers, another for network protocols etc. 18:39:32 if we decide to do this, i'll work on it next week 18:39:58 jwb: maybe post one of the generated configs to gobby, and we can all comment on it ? 18:40:10 davej, yeah, good idea 18:40:42 i think we need to parameterize the whole thing, so it can be driven by a list of modules separate from the specfile 18:40:50 #action jwb will post a generated config in gobby for input on which drivers to lump into a subpackage 18:41:17 cebbert, could be done by a plain file that gets included in a Source line or something 18:41:59 yeah 18:41:59 trickiest part will be debuginfo, but i think if we can leave that as-is that will probably be fine 18:42:14 e.g. all the debuginfo is still in kernel-debuginfo and kernel-debuginfo-common 18:42:19 ugh 18:42:45 well, it's either that or having kernel-debuginfo-esoteric 18:42:46 hmm 18:42:47 but yeah, given these are rarely used, it shouldn't be a big deal 18:43:00 when i look at it, i'll look at both ways 18:43:08 is that legal, or will some debug tool complain? 18:43:14 who knows 18:43:20 testing required 18:43:20 roland 18:44:07 so have we decided to go for this? 18:44:32 but having the debuginfo all in one place should be fine if it's legal 18:45:15 #agreed We will have a separate package (or packages) for rarely-used modules 18:45:19 jwb: I think it's something we can try. even if it turns out to be a terrible idea, we can revert without causing too much grief. 18:45:36 cool. what do we call it? 18:46:02 kernel-crap probably isn't going to fly 18:46:18 rare-modules kind of implies there are well done modules. 18:46:21 *badoom-tish* 18:46:21 kernel-flotsam 18:46:38 heh 18:46:42 doesn't ubuntu do something similar ? what do they call theirs ? 18:47:23 they have a linux-restricted-modules 18:47:32 that's an odd name 18:47:40 i think it's for non-free stuff 18:48:00 I don't like 'unsupported', because that implies there's some level of support for the rest. 18:48:22 in the absense of a better name, go with rare-modules. 18:48:32 if something better comes up, great 18:48:37 kernel-modules-extra 18:49:05 i think it's got to be kernel-modules- in any case 18:49:08 oh, we could go like gstreamer 18:49:11 kernel-modules-bad 18:49:28 kernel-modules-ugly 18:49:34 either is fine with me. i suggest we decide by brazilian jujitsu 18:49:37 1-2-3 FIGHT 18:49:39 heh 18:49:54 i know, we could have a vote 18:50:12 #action jwb to start prototyping kernel-modules- next week 18:50:21 kernel-modules-mustard 18:50:26 hah 18:50:47 cebbert, this is kind of the opposite of mustard 18:51:01 -mustard is for non-upstream modules. 18:51:28 ok. so we've got sort of a plan here it seems. 18:51:44 we'll see how it looks next week when we start going through the config 18:51:45 yeah. i'll get the gobby thing up today, we can review it throughout the week 18:52:03 that won't prevent me from working on the spec stuff, so no rush 18:54:07 ok, guess we're done ? 18:54:32 smolt? 18:54:36 let's queue up smolt for next meeting 18:54:51 fine with me 18:54:55 basic idea is "is it something we can fix to make it useful for us" 18:55:03 so thoughts along those lines would be good 18:55:23 yeah, i was thinking about using it for testing 18:55:27 sort of like davej has been doing with the abrt bugs, but i suspect we might have to actually work on smolt ourselves 18:55:58 anyway, we managed to fill an hour again. not bad 18:56:33 and my lunch just arrived. perfect timing. 18:56:42 heh 18:57:11 ok, i'll end the meeting if nobody else has anything 18:57:21 ok with me 18:57:26 word 18:57:39 #endmeeting