00:00:49 <jlaska> #startmeeting F-13-Final readiness meeting
00:00:49 <zodbot> Meeting started Wed May 12 00:00:49 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:01:00 <jlaska> #meetingname f-13-readiness
00:01:00 <zodbot> The meeting name has been set to 'f-13-readiness'
00:01:12 <jlaska> #topic Gathering crit-mass
00:01:19 * poelcat 
00:01:22 * stickster 
00:01:41 * jlaska 
00:01:56 * etank is here to lurk
00:02:16 * jlaska experiencing long irssi lag
00:02:33 <jlaska> I see Oxf13 as well
00:02:59 <jlaska> adamw: is likely here (Canucks are on tonight)
00:03:38 <jlaska> I don't think notting is available, perhaps spot in his absence?
00:03:49 <adamw> i'm here
00:03:55 * jlaska tips hat
00:05:09 <jlaska> let's get moving ...
00:05:19 <jlaska> #topic Why are we here?
00:05:27 <jlaska> Quick recap for folks new to this meeting
00:05:50 * spot is here
00:05:58 <jlaska> #info The purpose is to decide whether the Final release criteria have been met
00:06:05 <jlaska> #link https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria
00:06:15 * nirik is lurking around too.
00:06:26 <jlaska> welcome etank spot nirik
00:06:49 <jlaska> For those playing the home game, details on this meeting are available at http://fedoraproject.org/wiki/Engineering_Readiness_Meetings
00:07:06 <jlaska> Now for the main event ...
00:07:13 <jlaska> #topic Go or No Go?
00:07:34 <adamw> i'll take suitcase #14
00:08:07 <jlaska> First off, there remains OPEN (NEW + ASSIGNED) F13Blocker bugs on the list
00:08:23 <jlaska> #info OPEN F13Blocker bugs -- http://tinyurl.com/2v5hyqu
00:08:31 * poelcat notes that is criteria #2
00:08:44 <Oxf13> that should be changed slightly
00:08:48 <Oxf13> to open /accepted/ blockers
00:08:56 <Oxf13> since anybody can toss a bug on the blocker list
00:09:04 <jlaska> #info All bugs blocking the F13Blocker tracker must be CLOSED
00:09:32 <adamw> basically we should discuss whether to accept these proposed blockers here
00:09:33 <jlaska> I'm open to walking the list *briefly* for issues QA couldn't negotiate the impact on
00:09:50 <poelcat> are there any obvious ones that can be removed?
00:10:02 <Oxf13> From my viewpoint, none of the current bugs on the list constitute a Fedora 13 blocker.
00:10:43 <adamw> let's just take 'em in order?
00:10:57 <Oxf13> sure
00:11:07 <jlaska> Yeah, let's start with 588147
00:11:16 <jlaska> #info https://bugzilla.redhat.com/show_bug.cgi?id=588147
00:11:26 <Oxf13> what order are you working in?
00:11:57 <jlaska> Oxf13: I'm going by the tinyurl link above ... I'll just shout out the numbers if that's okay with folks?
00:12:06 <adamw> topic it
00:12:14 <Oxf13> sure, it's just that the bug you mention was in the middle of the list
00:12:40 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=588147
00:12:55 <Oxf13> anyway, this is an abrt crash, which I can't reproduce, and doesn't seem to be reproducible by many other people.
00:13:08 <adamw> yeah, this is a very newly-sprung one
00:13:15 <adamw> it'd be nice to know what the actual problem is here
00:13:29 <jlaska> #info In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)
00:13:41 <adamw> mclasen seems to be offline
00:13:44 <jlaska> I've only seen 1 report of this issue, so the "in most cases" is under question
00:13:45 <Oxf13> the person updated on May 1st, you'd think we'd have seen a lot more noise on this if it was systemic
00:13:49 <adamw> does anyone have an impact assessment?
00:13:52 <adamw> Oxf13: agreed
00:14:40 <adamw> the changelog just says "- Fix a crash due to a race condition at login ", which isn't terribly revealing
00:15:39 <spot> yeah, i haven't seen this on any of my installs
00:15:42 <jlaska> ENOTENOUGHINFO
00:15:51 <Oxf13> not sure how much more time we need to spend here.  Does anybody really think this is a issue worthy of slipping the release for?
00:15:52 * stickster hasn't seen this on any of his F13
00:16:06 * etank has not seen this at all either
00:16:15 * jlaska starts #agreed
00:16:30 <adamw> given the lack of dupes, no. but it would be nice to know what the actual bug is :(
00:17:08 <jlaska> #agreed 588147 - not a release blocker - unable to reproduce, unclear whether reported problem remains, not a lot of reports from testers about this failure
00:17:19 <jlaska> Next ...
00:17:25 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590640
00:17:38 <poelcat> want me to paste the "agreed" actions to the bugs?
00:18:00 <Oxf13> this one worried me at first, but now it seems we can't reproduce it
00:18:02 <jlaska> poelcat: please, that'd be great
00:18:04 <adamw> jlaska: what's your latest word on this?
00:18:09 <jlaska> I'm still a bit concerned on this
00:18:28 <jlaska> #info discovered while testing NFS installs (http://fedoraproject.org/wiki/Test_Results:Current_Installation_Test)
00:18:48 <jlaska> I thought I had this reproduced, boot.iso + repo=nfs:server:path
00:18:56 <Oxf13> to be fair, we don't list what the expected boot method is
00:18:59 <spot> jlaska: yeah, i think this is a blocker, although it is troublesome that you can't reproduce it
00:19:04 <Oxf13> both for the test, and for anaconda support
00:19:09 <jlaska> However, there may be more to it.  So far, kparal, rhe and I have all encountered this issue
00:19:14 <Oxf13> when you boot via pxe, this certainly doesn't happen
00:19:24 <stickster> http://docs.fedoraproject.org/install-guide/f13/en-US/html/ch04s06s02.html <-- documentation for prepping a NFS install
00:19:30 <Oxf13> which in my opinion is the more common NFS install boot method
00:19:34 <adamw> any anaconda folks to give an assessment of this>
00:19:34 <jlaska> Yes, booting just the vmlinuz+initrd.img (PXE) doesn't trigger this failure
00:19:35 <adamw> ?
00:19:36 <spot> "The installer must be able to use all supported local and remote package source options "
00:20:06 <jlaska> I honestly think the more common case is to boot some form of physical (DVD, CD or boot.iso), but I could be wrong
00:20:51 <jlaska> We could always provide an updates.img to use for this network install scenario, but it's just unsettling that we don't know root cause yet
00:20:56 <stickster> http://docs.fedoraproject.org/install-guide/f13/en-US/html/s1-begininstall-nfs-x86.html <-- the second half of NFS installation docs.
00:20:59 <jlaska> dlehman is lurking, but not sure if he's still around
00:21:09 <jlaska> stickster: thx teading
00:21:28 <adamw> what i'd really like is a better understanding of the bug, but this meeting is now :(
00:22:20 <jlaska> The installation instructions don't specify the boot media for the NFS install
00:22:29 <stickster> He Rui reported he was able to reproduce this?
00:22:48 <jlaska> Yeah, she, Kamil and I all hit the bug
00:22:52 <adamw> ]she
00:23:00 <stickster> oops, my apologies
00:23:04 * stickster doesn't know He
00:23:12 <jlaska> they encountered it while using boot.iso (I think)  and a local NFS mirror of branched
00:23:26 <spot> i think even if a reproducer is elusive, the fact that 3 qa testers hit this make it a legit blocker
00:23:31 <Oxf13> which could indicate a problem with their local mirror
00:23:35 <jlaska> I encountered this using the boot.iso and a local NFS exploded DVD image
00:23:39 <Oxf13> ah
00:23:48 <Oxf13> but you can't re-encounter it
00:24:11 <jlaska> My latest theory is that NetworkManager was recycling the IP while I was off doing something else, I hit Next and it crashes
00:24:23 <jlaska> somehow losing the nfs handle or connecting in the interim
00:24:32 <jlaska> but that's just a theory and still need to chase this down
00:24:52 <jlaska> so ... shall we vote?
00:24:53 <Oxf13> I can't duplicate it here using boot.iso and the branched NFS tree
00:25:26 <jlaska> Oxf13: I've retested many times today with boot.iso and local nfs exported DVD ... and hit it 1 of 5 attempts
00:25:39 <jlaska> so I think there might be more to it than than just boot.iso + repo=nfs:server:path
00:25:45 <jlaska> but just don't have that info yet
00:26:08 <Oxf13> wait, I take it back.  I did manage to hit it, it just happened much later than I would have expected.
00:26:21 <jlaska> it's after reposetup, and right when you start package install
00:26:30 <jlaska> so .. I'll start ...
00:26:31 <Oxf13> well that's a bummer :/
00:26:34 <adamw> so that's another one who's hit it
00:26:39 <spot> jlaska: i wonder if cache-fs is to blame here
00:26:51 <spot> jlaska: the traceback shows it being initialized
00:26:51 <Oxf13> boy that'd be shitty if this is what causes us to slip
00:26:56 <adamw> +1 blocker...it's too obviously icky and uncertain :/
00:26:59 <spot> +1
00:26:59 <jlaska> spot: hmm, didn't think of that ... could be
00:27:24 <Oxf13> so, we have a couple workarounds though.
00:27:50 <jlaska> Oxf13: I was trying to find a more comprehensive list of workarounds, but hadn't pinpointed the reproducer yet to fully expore those
00:27:52 <spot> jlaska: it might be worth seeing if there is a way to disable that and see if it works around the issue
00:28:13 <jlaska> spot: I can do that
00:28:24 <jlaska> do we want to agree on whether this is a blocker for this meeting
00:28:32 <jlaska> and we can then discuss how to handle the issues?
00:28:40 <jlaska> whether it's a slip, or continued debugging etc...
00:28:43 <spot> sorry. +1 for a blocker.
00:28:44 <adamw> if we agree it's a blocker then the release slips, afaik.
00:28:44 <Oxf13> well, this is the go / no go, so...
00:28:59 <poelcat> jlaska: seems like it is doesn't meet the criteria and there is no clear work around
00:29:18 <Oxf13> there is a clear work around
00:29:18 <stickster> It meets the criteria, at least #3
00:29:27 <Oxf13> boot using vmlinzu and initrd instead of boot.iso
00:30:16 <jlaska> Oxf13: That is a valid workaround, but requires a PXE setup, or an existing installed system
00:30:16 <spot> Oxf13: I'm not entirely sure that's clear, but even if so, i'm not really convinced that "use a different install method" is an acceptable workaround, given criteria #3
00:30:32 <Oxf13> spot: you're confusing "install method" with "boot method"
00:30:32 <nirik> or boot.fedoraproject.org ?
00:30:50 <jlaska> I'm 100% not comfortable with that workaround
00:31:04 <Oxf13> I really don't feel that it's super common to boot with spinning boot media and use an NFS source
00:31:24 <spot> well, its either supporter or it isn't.
00:31:28 <jlaska> Oxf13: so you're a -1 for blocker
00:31:35 <spot> i don't think "super common" is in the criteria.
00:31:52 <spot> supported, rather.
00:31:56 <Oxf13> spot: for the sake of slipping the release for a week I think "super common" absolutely matters.
00:31:57 * spot is tired.
00:31:58 * stickster could say what he feels about that kind of scenario based on his previous job, but we're just throwing around guesses.
00:32:02 * etank has personally never done a NFS based install.
00:32:26 <Oxf13> jlaska: yes, I'm -1
00:32:55 <jlaska> I think we have the votes that this is a blocker :(
00:33:15 <jlaska> that or we change the criteria
00:33:39 * poelcat thinks now is not the time to go down that road
00:33:45 <stickster> poelcat: +1
00:33:48 <spot> poelcat: +1
00:33:56 <poelcat> that's why we did this in December :)
00:34:13 <Oxf13> which is great and all, if we had a 8-ball and could see into the future
00:34:22 <Oxf13> sometimes you just don't think through all situations until you hit them.
00:34:24 <jlaska> poelcat: down the road of adjusting the criteria?
00:35:08 <jlaska> oh sorry, misread
00:35:24 <jlaska> yeah, I'm not sure what else to say on this bug
00:35:53 * jlaska prepares the #agreed stamp
00:35:57 * nirik plays the sad sliping trombone
00:36:24 <Oxf13> really going to ruin my day.
00:36:46 <Oxf13> it just seems silly we're going to throw it all away for an issue that hardly seems common, certainly not common enough to find it before a day or so ago.
00:36:47 <nirik> do we want to look at the rest of them before deciding for sure? or is this it...
00:37:07 <adamw> if a bug's a blocker, we slip.
00:37:10 <stickster> nirik: If we have a blocker identified that's not cleared, that's it.
00:37:11 <jlaska> #agreed 590640 - a valid blocker bug, still uncertain how far the impact may extend.  Boot.iso + repo=nfs:server:path likely impacted
00:37:21 <Oxf13> It's still worth going through the rest
00:37:22 <adamw> we could look at what else we would take fixes for, though, i guess.
00:37:41 <Oxf13> although right now, I really don't feel like spending any more time on Fedora.
00:37:44 <poelcat> adamw: why would we do that if it is blocker only from here on out?
00:38:06 <jlaska> #info some debate around how common NFS installs are for users
00:38:06 <nirik> because we might want to fix other blockers before we try again?
00:38:24 <adamw> poelcat: to decide if they're blockers and hence also need to be fixed :)
00:38:30 * Oxf13 thinks we're getting a little too wrapped up on following the letter of our criteria instead of applying a little judgment.
00:38:32 <jlaska> let's clear as much of this list
00:38:33 <poelcat> adamw: sorry, i took that the wrong way
00:38:53 <poelcat> Oxf13: what part of the criteria do you feel needs ammending?
00:39:13 <Oxf13> poelcat: the part that is making us slip because of this bug.
00:39:18 <jlaska> Oxf13: I agree there is a degree of judgement that is needed, but in this case we don't fully understand the failure conditions.  So it's hard to say what the full impact is for me
00:39:24 <adamw> Oxf13: i don't agree, i tink it's reasonably clearcut: we decided NFS is a supported install path and we can't release the product with our supported install paths not working. nfs install clearly is not working properly. ergo we don't release the product that way.
00:39:42 <Oxf13> adamw: NFS as an install path works, provided you boot via pxe
00:39:51 <Oxf13> which in my experience has been the far more common case when doing NFS base dinstalls
00:40:03 <stickster> Whereas my experience has been the opposite :-)
00:40:05 <adamw> never mind, circular.
00:40:34 <Oxf13> if NFS didn't work with any boot method, that'd be one thing.
00:40:38 <jlaska> Next bug ...
00:40:55 <spot> yeah, lets move on, this horse isn't getting any deader.
00:41:04 <Oxf13> stickster: if that were really the case, why did it only show up... yesterday?  We haven't changed anaconda in while.
00:41:44 <jlaska> Oxf13: good questions, and we'll definitely have that debate once we figure out root cause
00:41:51 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590874
00:42:30 <jlaska> "funny", this might be the cause for the NFS failure
00:42:40 <jlaska> but again, speculation
00:42:42 <Oxf13> it's not
00:43:04 <Oxf13> simple work around here, don't check UTC, or set your PC clock correctly before doing the install
00:43:16 <jlaska> I was seeing a lease renew attempt from NM in my failure cases of the previous bug
00:43:17 <spot> uhh, don't check UTC?
00:43:23 <jlaska> Isn't UTC default?
00:43:26 <spot> yeah.
00:43:54 <Oxf13> I think the situation is when the PC clock is not already set to UTC, or is wildly off
00:43:56 <adamw> the report says to *uncheck* system clock uses UTC
00:44:16 <jlaska> I managed to reproduce the clock jump. Just set your timezone to the other half
00:44:17 <adamw> (to reproduce the bug)
00:44:17 <Oxf13> oh right
00:44:20 <jlaska> of the world and uncheck "system clock uses UTC", that should do it.
00:44:28 <jlaska> ^^that was from Orion in the bz
00:44:31 <Oxf13> so if you leave the default, it'll work
00:44:57 * jlaska has the spidey sense that this and the previous bug are related
00:45:03 <adamw> yes, but 'the default' isn't always the right choice here; it's a simple fact whether your system clock is set to UTC or not, it's not really a matter of preference whether you select it or not
00:45:31 <jlaska> does this issue impact the final release criteria?
00:45:37 <adamw> (i believe the point here being that windows doesn't really work right with the system clock set to UTC?)
00:45:37 <stickster> So am I correct that this would bite just about anyone in Asia who's already using UTC (e.g. a current Linux user)?
00:45:57 <adamw> stickster: no, it affects you if your clock does *not* use UTC (and you're aware of this and intentionally uncheck that box)
00:46:04 <stickster> Ah, OK
00:46:12 <stickster> Thanks -- so more like the dual-boot user then.
00:46:13 <Oxf13> stickster: I think you'd have to uncheck use UTC, and/or have your system clock already set to something vastly wrong.
00:46:52 <Oxf13> adamw: I think that's older versions of windows.  My dualboot system handles UTC just fine with vista
00:47:23 <adamw> ok
00:47:36 <spot> yeah, i think this is a reasonably minor issue, nice to fix given that we're slipping, but not a blocker.
00:48:00 <adamw> given that we're now essentially asking 'do we take a fix for this bug', it might be good to have an opinion from hughsie on the impact and the impact of a fix
00:48:37 * nirik cautions against 'oh, we are slipping, lets fix these 100 things'
00:48:38 <Oxf13> hughsie?
00:48:44 <jlaska> I gather he's not a Canucks fan?
00:48:52 <spot> nirik: agreed
00:48:54 <stickster> nirik: Yup, we need to be very selective
00:49:08 <Oxf13> adamw: perhaps you mean dcbw ?
00:49:14 <adamw> d'oh
00:49:21 <adamw> does it show i've been drinking all night? :)
00:49:47 <jlaska> I don't think we'll get an answer on this one here
00:50:13 <jlaska> if we comfortable taking a well tested and isolated fix, we can F13Target this issue and move on
00:50:29 <stickster> jlaska: Insert a comment in bug looking for impact assessment? Or manage that elsewhere?
00:50:29 <spot> jlaska: +1
00:50:34 <Oxf13> bottom line we have to decide if this was the last bug on the list, would we slip the release for it
00:50:40 <Oxf13> in my opinion, that's no.
00:50:59 <jlaska> stickster: both, CommonBug, and ping the bz for impact assessment
00:51:04 <stickster> jlaska: thanks
00:51:17 <jlaska> I'm +1 to F13Target for this
00:51:38 <adamw> sure
00:51:39 <spot> +1 to F13Target
00:51:42 <jlaska> anyone else?
00:52:39 <stickster> move on, looks like
00:52:49 <jlaska> #agreed 590874 - Move to F13Target, add to CommonBugs and seek impact assessment
00:52:59 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590960
00:53:31 <jlaska> adamw's comment#5 sums it up for me
00:53:52 <Oxf13> yea, -1 on blocker.
00:54:04 <jlaska> -1 on blocker
00:54:12 <stickster> I have a 8400M GS that works fine, fwiw
00:54:27 <adamw> although on comment #8 i'd like to know if it's the exact same card that fails in the other machine
00:54:32 <etank> i have 2 different systems with nvidia cards and i have never seen this
00:54:33 <adamw> but overall, -1
00:54:39 <spot> -1, workaround known anyways
00:55:12 <jlaska> #agreed 590960 - not a blocker, no widespread reports of 8400M failures
00:55:31 <stickster> jlaska: You may want to back that out -- I checked the OP's smolt and it's a 8600 GT
00:55:34 <jlaska> I'm skipping the preupgrade bug 587627 .. hughsie has a handle on this, is aware that this needs to be fixed and available in F12
00:55:41 <jlaska> #undo
00:55:41 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x178cc910>
00:55:52 <jlaska> so same decision, but with 8600GT?
00:55:59 <adamw> yes
00:56:02 <stickster> My fault -- I misread comment #5
00:56:18 <adamw> even if all 8600GT's fail, it's a single model, we don't usually block for that. especially since there's an (ugly) workaround.
00:56:27 <stickster> agreed
00:56:34 <jlaska> #agreed 590960 - not a blocker, no widespread reports of failures with reported chipset
00:56:51 <jlaska> last one ... one we're all familiar with
00:56:52 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=590661
00:57:25 <spot> fwiw, i still think this is a blocker, behavior regression.
00:57:42 <jlaska> #info I reached out to FESCO for their opinion on the blockery-ness of this issue (see https://fedorahosted.org/fesco/ticket/377)
00:57:43 <adamw> frankly if the fix for this is low-impact i'd *really* like to take it.
00:58:10 <Oxf13> Fesco voted to not slip specifically for it
00:58:10 <jlaska> perhaps it's book keeping at this point, but based on FESCO's review, shall we move this to F13Target
00:58:21 <jlaska> and accept a  well tested fix for the issue?
00:58:22 <Oxf13> but since we're slipping, and since the fix is very low impact, we can take it
00:58:33 <spot> jlaska: sure, end result is the same.
00:58:37 <stickster> adamw: +1, doubly so (+2?) because a number of factors coincide to make this exactly the kind of bug that could be a ridiculous amount of bad press for us for no good reason
00:58:38 <jlaska> spot: yeah
00:58:47 <Oxf13> however, I think we should still move this to Target, since we would likely make the same decision if it for whatever reason was still broken next week
00:59:22 <adamw> sure, make it target not blocker, that's fine.
00:59:30 <jlaska> #agreed 590661 - should move to F13Target, will accept a well tested fix for this issue considering the potential negative press
00:59:37 * spot isn't sure i agree with that, but given that there is a tested fix in hand... whatever.
00:59:51 <jlaska> spot: roger
01:00:03 * stickster neither, but it's not worth arguing right now since we have our decision for slip already
01:00:07 * nirik thinks it's kinda moot.
01:00:09 <jlaska> #partial-agree :)
01:00:13 <stickster> "I get the car, I get the house"
01:00:19 <jlaska> heh
01:00:21 <jlaska> okay, that's the list
01:00:38 <spot> what about 587627?
01:00:43 <jlaska> again, I'm skipping the F-12 preupgrade issue
01:00:51 <spot> okay.
01:01:10 <adamw> rationale: the bug is in f12's preupgrade, it doesn't affect f13 compose
01:01:12 <spot> 588597?
01:01:18 <jlaska> We can discuss that if folks want, but hughsie is aware of the deadline for deliverying the F-12 preupgrade
01:01:26 <adamw> it blocks f13 _release_ but not _compose_, we only need to ship an f12 update in time for f13 release to be okay
01:01:29 <etank> so down to 3 blockers then. less is better.
01:01:42 <adamw> (we've been through this dance with f12, we more or less have a procedure for it)
01:01:46 <Oxf13> not even 3
01:01:54 <nirik> 1 ?
01:01:56 <Oxf13> AFAIKT there is exactly one issue we're slipping for
01:01:57 <stickster> spot: That's MODIFIED, I think it's tagged ?
01:02:07 <spot> stickster: yeah, you're right, sorry
01:02:16 <jlaska> Oxf13: you can move that issue to VERIFIED now?
01:02:17 * stickster willing to be corrected by smart folk
01:02:25 <spot> 588021
01:02:30 <Oxf13> which issue?
01:02:32 <spot> i don't think that there is a confirmed fix there
01:02:40 <spot> even though it is in MODIFIED
01:02:43 <jlaska> Oxf13: 588597
01:03:15 <jlaska> do we want to #topic through the MODIFIED F13Blockers ?
01:03:29 <spot> jlaska: the only one that seems to be noteworthy imho is 588021
01:03:39 <nirik> .bug 588021
01:03:41 <zodbot> nirik: Bug 588021 iwlagn hangs the system randomly due to a rate scaling bug - https://bugzilla.redhat.com/show_bug.cgi?id=588021
01:04:00 <spot> especially given that there is only a scratch build done for it
01:04:02 <jlaska> adamw: have you seen any forum reports of success with F-13-RC?
01:04:40 <stickster> spot: adamw: The current kernel is -85, right? That would have the iwlagn fix I see noted
01:05:07 <spot> stickster: are you sure?
01:05:14 <adamw> yes, -85 ought to have the fix
01:05:23 <stickster> spot: I have a local mirror of f-l-development/13/x86_64/ I'm referring to
01:05:29 <Oxf13> $ koji latest-pkg --quiet dist-f13 kernel
01:05:29 <Oxf13> kernel-2.6.33.3-85.fc13                   dist-f13              ajax
01:05:30 <adamw> jlaska: the forum threads may not be reproducers; there's no direct feedback etiher way
01:05:45 <stickster> thanks Oxf13
01:05:47 <adamw> spot: -85 is definitely the kernel in rc2. i've been testing it all day. =)
01:06:05 <spot> no, i mean, are you sure it has the fix from the scratch build?
01:06:06 <jlaska> recommendations?
01:06:49 <Oxf13> Tue Mar 30 2010 John W. Linville <linville@redhat.com> 2.6.33.1-24
01:06:49 <Oxf13> - Avoid null pointer dereference introduced by 'ssb: check for sprom' (#577463)
01:06:51 <stickster> spot: the changelog indicates that was in -82
01:07:01 <spot> Oxf13: that's not it
01:07:07 <Oxf13> whoops, wrong kernel
01:07:11 <adamw> * Tue May 04 2010 John W. Linville <linville@redhat.com> 2.6.33.3-82 - iwlwifi: recalculate average tpt if not current (#588021)
01:07:14 <stickster> That's it
01:07:25 <Oxf13> * Tue May 04 2010 John W. Linville <linville@redhat.com> 2.6.33.3-82
01:07:25 <Oxf13> - iwlwifi: recalculate average tpt if not current (#588021)
01:07:28 <spot> okay. just being thorough. :)
01:07:31 <Oxf13> adamw beat me to it.
01:07:34 <spot> it wasn't clear from the bz
01:07:35 <stickster> :-)
01:07:37 <jlaska> so all signs seem to indicate a fix is available, still waiting on test confirmation?
01:08:05 <stickster> FWIW I'm using -85 and iwlagn here for some time now.
01:08:38 <adamw> yeah, confirmation from reporters would be nice.
01:08:38 <jlaska> Any other bugs before moving to next #topic ?
01:08:49 <Oxf13> I'm on iwlagn but kernel -72
01:08:51 <Oxf13> and no issues
01:08:57 <Oxf13> so I don't know that I can help
01:09:09 <jlaska> #topic https://bugzilla.redhat.com/588021
01:09:32 <jlaska> #info fix appears to be included in 2.6.33.3-82 kernel (in RC#2)
01:09:45 <jlaska> #help confirmation of fix from reporters would be appreciated
01:09:57 <jlaska> Okay, let's end this meeting ...
01:10:06 <jlaska> #topic What's next?
01:10:23 <jlaska> announcements, schedule adjustments?
01:10:43 <adamw> a warm fuzzy alcohol-induced coma?
01:10:46 * adamw is all for option C
01:10:55 <jlaska> that was a given
01:11:26 * poelcat still planning to do Release Readiness meeting on Thursday--hopefully everything else is on track
01:11:51 <jlaska> #info QA to continue to test bug#590640 and work with dlehman on problem determination
01:12:06 <jlaska> #info Poelcat planning to do Release Readiness meeting on Thursday
01:12:14 <stickster> #action stickster changing [[Schedule]] page on wiki
01:12:30 * poelcat will update taskjuggler
01:12:34 * jlaska recommends liberal use of #info and #action for all
01:13:18 <jlaska> anything else need ownership?
01:13:22 <stickster> #action stickster notifying Red Hat components for PR and redhat.com web promo
01:13:33 <poelcat> who is sending out the fedora announcement?
01:13:53 <stickster> I think Oxf13 generally does
01:14:07 <Oxf13> I suppose I can, just not tonight.
01:14:16 <stickster> Oxf13: I'll do it for you if you like
01:14:18 <jlaska> #action jlaska (Mr. Minutes) will send meeting minutes to test@ and devel@
01:14:25 <stickster> I'll refer to your previous text for a pony
01:14:28 <Oxf13> stickster: go for it
01:14:37 <stickster> #action stickster send slip notice in the style of Oxf13
01:15:20 <jlaska> okay gang ... if nothing else, I'll #endmeeting in 2 minutes
01:16:42 <jlaska> 1 minute until #endmeeting
01:16:44 <stickster> I'll note that rel-eng+QA plan to be very conservative of accepting any fixes other than those identified for blockers or critical bugs
01:16:57 <stickster> s/of/when/   <-- ugh, grammar fail.
01:17:13 <jlaska> yes please!  We're cutting into some quality Retrospective time :)
01:17:53 <jlaska> alright folks, thanks for your time and brains
01:18:07 <jlaska> #endmeeting