16:05:34 <adamw> #startmeeting Fedora 13 Alpha blocker bug review meeting #1
16:05:34 <zodbot> Meeting started Fri Feb  5 16:05:34 2010 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:43 <adamw> #meetingname alphablocker1
16:05:44 <zodbot> The meeting name has been set to 'alphablocker1'
16:05:48 <adamw> yay.
16:06:16 <adamw> alrighty then, I guess we know the drill by now: we'll go through the existing alpha blocker bugs one by one, and evaluate them
16:06:28 <warren> URL?
16:06:33 <adamw> https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&field0-0-0=blocked&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&type0-0-0=substring&value0-0-0=%20538273&product=Fedora&classification=Fedora
16:07:14 <adamw> #url https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&field0-0-0=blocked&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&type0-0-0=substring&value0-0-0=%20538273&product=Fedora&classification=Fedora
16:07:20 <adamw> so, first bug is a sensitive one:
16:07:25 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=557386
16:07:53 <adamw> ...
16:07:55 <jlaska> ah right
16:08:00 * adamw kicks zodbot
16:08:15 <stickster> is zodbot voiced/op?
16:08:28 <adamw> oh well. yep, this is abrt being broken. we're not united over whether this should block the alpha.
16:08:30 <adamw> apparently not
16:09:25 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=557386
16:09:29 <adamw> for great justice!
16:09:42 <adamw> ok, so, yeah, opinions? should abrt being broken block the alpha?
16:09:50 <adamw> should it block *alphas in general*?
16:10:16 <jlaska> adamw: one sec ...
16:10:35 <jlaska> well, we noted that the isntaller must be able to report failures to bugzilla for the Alpha
16:10:41 <jlaska> it seems logical to extend that to ABRT
16:11:04 <adamw> i think it is *on the basis of live image testing*
16:11:18 <jlaska> what is?
16:11:28 <adamw> extending the installer bug report premise
16:11:39 <jlaska> oh, I don't think so
16:11:42 <adamw> for installed alphas, it doesn't follow, because we can fix it with an update
16:11:49 <adamw> (which doesn't apply to the installer)
16:12:09 <jlaska> chicken ... meet egg
16:12:12 <adamw> but if we ship alpha with abrt broken, then anyone testing a live image doesn't get it working. especially since the bug's in the kernel
16:13:12 <jlaska> how does live image come into play? does this only surface on live images?
16:13:20 <adamw> no, but you can't update a live image
16:13:26 <jlaska> I see
16:13:39 <adamw> well you CAN, but most people won't. and you can't update the kernel, where this bug is.
16:13:50 <pjones> I think adamw's point is a good one
16:14:06 <jlaska> we hit this often
16:14:12 <pjones> it's effectively analogous to anaconda traceback filing not working, but in the livecd case.
16:14:25 <adamw> right.
16:14:36 <jlaska> yeah, and we block for that
16:14:41 <jlaska> am I missing something?
16:15:42 <adamw> nothing I can see
16:15:52 <adamw> so let's leave it on the list, and maybe add an explicit criterion
16:16:14 <adamw> alright, so the status is that the kernel folks think they have what abrt folks need
16:16:24 <adamw> and we're waiting on abrt folks to confirm. (but it's only been a few hours.)
16:16:48 <adamw> jiri's been pretty outspoken on this, so i'm sure he'll be on top of it quickly.
16:17:01 <jlaska> I was just going to ask ... if we needed to pull him in
16:17:11 <jlaska> since brno will probably be dropping off soon
16:17:30 <adamw> i dunno if it's necessary...maybe it's worth a quick poke
16:17:42 <jlaska> okay, I'll reach out
16:17:54 <adamw> beat you to it :)
16:18:46 <jlaska> heh, well ... I'm sure he'll appreciate the double ping then
16:18:48 <jlaska> :)
16:19:41 <adamw> well, not worth waiting a long time for, i think we can just move on
16:20:10 <jlaska> sounds good
16:20:20 <adamw> #info 557386 is agreed to remain a blocker (and release criterion will be added for abrt being broken), bug status is waiting for abrt team to confirm the fix provided by kernel team
16:22:40 <adamw> #info late-breaking news: jmoskovc confirms the 557386 change is what abrt team needs to make abrt work again
16:22:46 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=559290
16:23:36 <adamw> so, uh, this is one of the 'installation is broken' bugs?
16:23:44 <jlaska> well, sort of
16:23:46 <jlaska> lemme see ...
16:24:10 <jlaska> my understanding is it's turned into 512M not being enough
16:24:30 <jlaska> so ... you can install without LVM on a 512M system
16:24:54 <jlaska> but if you use LVM (or install to a system that previously had LVM partitions) on a system with 512M ... oomkill
16:25:19 <adamw> that's a bit...sucky. LVM is still our default layout, right?
16:25:27 <adamw> so this is now 'default Fedora install breaks with 512MB of RAM'?
16:25:44 <adamw> (only on x86-64?)
16:26:00 <jlaska> yeah only x86_64
16:26:16 <jlaska> so we can update the hardware requirements in the release notes
16:26:26 <jlaska> or chase down why it needs more memory now
16:26:27 <jlaska> ?
16:26:33 <drago01> wekk most x86_64 boxes should already have >512MB
16:26:37 <drago01> *well
16:26:46 <adamw> it may be reaching the point where it's annoying for VMs, though.
16:26:49 <jlaska> yeah, the case where we run into this was with virt guests
16:27:01 <jlaska> specifically with the default environment for rats_install
16:27:04 <adamw> i'd say it's quite common to run VMs with limited RAM.
16:27:16 <jlaska> we can change it of course, but 512M seems likeit should be sufficient to me
16:27:19 <adamw> and this does just feel bad on the face of it. i mean, come on, why does the OS installer need 512MB of frickin' RAM.
16:27:20 <drago01> yeah true
16:27:20 <jlaska> yeah
16:27:43 <jlaska> it's still assigned to anaconda, but I think perhaps could be moved to LVM
16:27:46 <adamw> i have linux, an IRC client, a browser, an email client and a couple of games running on my phone, in 180MB. :P
16:28:04 <pjones> yeah, the question is why we're getting oomkill so much
16:28:16 <drago01> adamw: but no lvm on your phone ;)
16:28:55 <pjones> (it really seems like we're hitting it without that much ram in use, but obviously this isn't imperical data on my part.)
16:29:50 <jlaska> we have alpha release requirements are the default install path, which includes LVM.  But we don't have any mention of the hardware environment
16:29:58 <adamw> i'm not sure this is an alpha blocker, but i think it may be a beta or final blocker...i really think we need to draw a line somewhere for the RAM bugs and not just have the answer be 'buy more RAM!'
16:30:24 <jlaska> note ... http://docs.fedoraproject.org/release-notes/f12/en-US/html/index.html#sect-Release_Notes-Hardware_Requirements
16:30:35 <jlaska> *
16:30:36 <jlaska> Minimum RAM for text-mode: 256 MiB
16:30:36 <jlaska> *
16:30:36 <jlaska> Minimum RAM for graphical: 384 MiB
16:30:38 <jlaska> *
16:30:41 <jlaska> Recommended RAM for graphical: 512 MiB
16:30:43 <jlaska> 
16:30:48 <jlaska> based on the analysis for this issue, that might need an update
16:31:00 <jlaska> s/analysis for/outcome of/
16:31:34 <jlaska> pjones: dlehman: should we reassign this to LVM?
16:32:02 <dlehman> what's the bug id?
16:32:09 <jlaska> 559290
16:32:23 <adamw> hiya tech33
16:32:34 <Tech33> adamw: hi there
16:32:39 <pjones> I don't know if it's lvm or the kernel
16:32:48 <pjones> probably somebody should talk to agk about it
16:32:48 <adamw> Tech33: we're in the blocker bug review meeting atm - please do throw in any X bugs you have your eye on when we hit the 'open floor' stage :)
16:33:14 <dlehman> lvm makes sense as a starting point. if they find out it's the kernel, fine
16:33:25 <jlaska> pjones: okay, I'll add agk to the cc and ask for input
16:33:49 <dlehman> but yeah -- it seems we need to up the min ram for x86_64 to 1GiB
16:34:02 <adamw> jlaska: i'd say this falls into the 'in most cases' hardware grey area, btw
16:34:28 <adamw> dlehman: well, i'd want to leave it as is for now, in case we can fix it before final
16:34:40 <adamw> once you bump a hardware requirement it's always strangely hard to un-bump it again :)
16:34:41 <jlaska> adamw: ah good point ...
16:34:42 <jlaska> https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F
16:34:45 <dlehman> makes sense
16:35:06 <adamw> so, we assign to LVM and drop to beta or final blocker?
16:35:29 <pjones> yeah, sounds right
16:35:32 <jlaska> agreed ... I'll update and move to beta
16:35:49 <pjones> fwiw, I /think/ I've seen similar problems on a machine with >1G of ram
16:36:14 <pjones> so I suspect what's going on is some allocation that's incorrectly from of the small zones
16:36:16 <jlaska> eew
16:36:19 <adamw> ok
16:36:52 <adamw> #agreed 559290 drops to Beta blocker, assign to LVM team for action
16:37:03 <adamw> #action jlaska to update 559290 and assign to LVM team
16:37:17 <jlaska> commonbug material for the alpha?
16:37:19 <adamw> #info pjones thinks this is a case of incorrect allocation, not actual genuine usage of large amounts of RAM
16:37:34 <adamw> hmm, good point - i think so
16:37:41 <adamw> let's stick the whiteboard on there
16:37:46 <adamw> can you do that too?
16:37:49 <adamw> er, keyword
16:37:59 <jlaska> you got it
16:38:18 * jlaska clicks submit
16:38:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=560334
16:39:11 <adamw> well, this looks like it should be closed, I guess?
16:39:14 <adamw> from comment #3
16:39:25 <jlaska> yeah seems so ...
16:39:34 <jlaska> did anything change in anaconda to address this?
16:39:36 <adamw> anaconda guys, does it make sense to you that this was fixed between 13.23 and 13.25?
16:39:38 <dlehman> I tried to reproduce yesterday but was unable to
16:39:39 <jlaska> or could his reproducer have gone away?
16:40:50 <jlaska> in that case, folks okay with closing it out?  We can always put it right back on the list if the issue resurfaces.
16:41:08 <adamw> okay
16:41:25 <adamw> #agreed 560334 looks to be resolved: reporter cannot reproduce and neither can dlehman
16:41:32 <jlaska> clyde is always good for install testing, so if he couldn't hit it again, that's a good sign
16:42:29 <dlehman> it wasn't clear to me what was happening in the first place, so I can't say if it should have been addressed by anything committed since 13.23-1
16:42:45 <adamw> ok
16:42:49 <adamw> well, we'll reopen if necessary
16:42:54 <dlehman> I suspect it's been fixed
16:43:00 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=562209
16:43:06 <jlaska> adamw: you want me bump that one?
16:43:22 <adamw> done it
16:43:42 <jlaska> sweet!
16:43:44 <adamw> 562209 is yours, james
16:44:02 <jlaska> ah yes ... saw this earlier in the week while testing RATS drop#2
16:44:12 <jlaska> filed this morning and someone else on #fedora-devel just reported it too
16:44:56 <Oxf13> I'm not going to be able to be here long, I have a prior commitment outside the house
16:45:09 <jlaska> Oxf13: fortunately the list isn't too bad yet
16:45:10 <adamw> seems pretty no-brainer
16:45:18 <adamw> yeah, this won't be a seven-hour blockbuster
16:45:28 <Oxf13> did anybody scour F13Blocker for things that should block Alpha?
16:45:29 <jlaska> we save those till the end right? :)
16:45:35 <adamw> Oxf13: we'll do that at the end if time permits
16:45:51 <adamw> (in other words, no, I'm a lazy ass and I didn't)
16:46:10 <jlaska> so for /topic bug ... I think it meets the Alpha criteria "#  The
16:46:10 <jlaska> installer must boot (if appropriate) and run on all primary architectures from
16:46:14 <jlaska> default live image, DVD, and boot.iso install media "
16:46:15 <adamw> yup
16:46:25 <adamw> don't think there's much to do here, just fix it, anaconda people :D
16:46:36 <Oxf13> k
16:47:04 <adamw> #agreed 562209 is a blocker, breaks 'installer must run from boot.iso' criterion. action is on anaconda team
16:47:13 <jlaska> clumens is already knee deep in it I believe
16:48:04 <pjones> Oh, I guess that was the problem I was seeing yesterday.  Good to know.
16:48:05 <adamw> #topic
16:48:07 <adamw> grr
16:48:13 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=557928
16:48:40 <adamw> another jlaska special
16:48:58 <jlaska> oh this yeah ... dlehman and I've talked about this
16:49:19 <jlaska> so for some storage failures, we prompt the user whether they want to file a bug or not
16:49:33 <adamw> so the issue here is the prompting, not the bug itself?
16:49:35 <jlaska> and when running through out automated tests, this means it doesn't spit out the traceback for us to file abug with
16:49:39 <jlaska> adamw: you got it
16:50:11 <jlaska> for kickstart, I believe the mantra is 'don't prompt', so I've added this is a RFE for the install guys input
16:50:23 <adamw> why is it an alpha blocker?
16:50:36 <jlaska> I think Oxf13 added this ... lemme check ...
16:50:39 <Oxf13> we will likely be doing a lot of automated testing for alpha
16:50:39 <jlaska> but ..
16:50:51 <Oxf13> I was just adding any anaconda bug that looked risky
16:51:11 <jlaska> #  The installer must be able to report failures to Bugzilla, with appropriate information included
16:51:25 <jlaska> perhaps grey area here, I like Oxf13's point
16:51:26 <dlehman> we don't like to prompt too much in kickstart, but we're not going to auto-file bugs w/o asking first
16:51:35 <jlaska> dlehman: of course, not asking for that here
16:51:47 <jlaska> dlehman: what would help our automation is just spitting out something so we recognize the traceback
16:51:48 <adamw> the intention of that criterion is 'anaconda's bug reporting mechanism must basically work', not 'absolutely all types of failure must be auto-reported correctly', i believe
16:51:53 <jlaska> and not timeout the test ... and have to dig into the timeout etc...
16:51:56 <dlehman> if you were to do that same test (and failure) in cmdline mode, what would happen?
16:52:20 <jlaska> dlehman: I could try ... but I don't think we'd want to change out test to use cmdline mode
16:52:40 <jlaska> adamw: yeah, that was my thinking as well
16:53:06 <jlaska> dlehman: we can adjust our automation if needed too, so not putting it all on installer team
16:53:14 <adamw> personally I wouldn't consider this a blocker; we can't elevate qa's own procedures to the level of defining what bugs block a release, I don't think? at least, not unless it's something really egregious.
16:53:56 <adamw> i.e. just because it inconveniences autoqa a bit doesn't make it a blocker. I dunno. well, it doesn't fit the criteria if we go with our original intention in writing them. as stated despotically by me. :P
16:54:01 <jlaska> dlehman: just looking for a way to get access to that traceback dump during kickstart installs
16:54:13 <jlaska> adamw: you despot! :)
16:54:29 <dlehman> it's worth taking a look at it to see how feasible it would be to write out the traceback before prompting
16:54:45 <adamw> sure, i'm not saying don't fix the bug, just talking about the blocker-or-otherwise-ness
16:54:52 <jlaska> I don't have objections with moving this to Beta, it's not a large impact to our testing at this time for Alpha
16:54:54 <dlehman> yep
16:55:08 <adamw> jlaska: which beta criterion does it satisfy? ;)
16:55:28 <jlaska> it might not hit any ... but i'll bring it up again for exception review then
16:55:31 * jlaska checking
16:55:39 <adamw> okay
16:55:57 <adamw> #agreed 557928 is not an alpha blocker, we will punt to beta for now. anaconda team is looking at it
16:56:04 <jlaska> just want to make sure we don't drop it
16:56:29 <adamw> alright
16:56:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=560477
16:57:08 <jlaska> oh nice, he must be creating his own DVD to test with?
16:59:00 <Oxf13> alright I have to step out now.  I'll be back later
16:59:15 <adamw> what's the status of the patch?
16:59:17 <adamw> thanks oxf13
16:59:35 <jlaska> adamw: lemme check anaconda git ... may not have landed in anaconda-13.25
16:59:47 <jlaska> pjones: https://www.redhat.com/archives/anaconda-devel-list/2010-January/msg00586.html ?
17:00:07 <pjones> yes, that is a post from me, why do you ask?
17:00:23 <pjones> (did I not push the patch yet or something?)
17:00:38 <jlaska> pjones: Hey, just trying to see if this was in anaconda-13.25 or will be in next week?
17:00:51 <jlaska> doesn't seem so looking at the rescue.py history (http://git.fedorahosted.org/git/?p=anaconda.git;a=history;f=rescue.py;h=4ae4d6f004c73d49379c08c057d0c5a1d1b81d1d;hb=refs/heads/master)
17:02:27 <jlaska> so I think we can leave that on the list, and reconfirm the fix once the patch is in?
17:02:57 <dlehman> pjones: looks like it didn't get pushed
17:03:08 <pjones> will do
17:03:08 <adamw> jlaska: sounds good to me
17:03:52 <adamw> #agreed 560477 is a blocker (breaks 'rescue mode most start successfully'), patch is written but not committed
17:03:59 <jlaska> can you use an updates.img for rescue-mode stuff?
17:04:03 <adamw> #action pjones to push patch to fix 560477
17:04:35 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=557323
17:05:01 <dlehman> should be able to use updates.img for rescue mode IIRC
17:05:04 <pjones> done.
17:05:15 <pjones> dlehman: yeah, that's how I tested it.
17:05:44 <jlaska> ah cool, thanks gents
17:05:45 <pjones> anyway, it's pushed to master now; should be in the next build
17:06:02 <adamw> ok
17:06:05 <jlaska> adamw: I've not seen this on recent RATS drops, so I'm inclined to close it out
17:06:14 <adamw> 557323 is silently marked MODIFIED
17:06:15 <jlaska> but we can ask Oxf13 if he's seen it as well
17:06:23 <adamw> what's the deal, anaconda folks?
17:07:16 <adamw> jlaska: or we could've done five minutes ago :P
17:07:24 <pjones> definitely looks like there's a traceback happening.
17:08:24 <pjones> So, I think that code got rewritten for unrelated reasons
17:09:05 <adamw> and now it probably works
17:09:31 <pjones> hrm,  or maybe just moved.
17:09:31 <dlehman> probably commit 8a87de5f857
17:10:07 <pjones> f3ac4679 (Chris Lumens  2010-01-07 13:12:52 -0500 621)             name = udev_device_get_name(d)
17:10:24 <pjones> looks like name should be there; if you're not seeing this now, it's probably accidentally fixed.
17:10:25 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=8a87de5f8573e4d800c02b99c09762e44f5666cd
17:11:17 <dlehman> yeah, looks all fixed up in current tree
17:12:19 * pjones goes to lunch
17:12:28 <adamw> okay
17:12:30 <adamw> let's close
17:12:50 <adamw> #agreed 557323 is probably fixed, according to anaconda team: will be closed
17:13:36 <adamw> two more to go!
17:13:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=559679
17:13:50 <adamw> didn't the fix for this get in already?
17:14:08 <adamw> pretty sure that selinux-policy is in rawhide now
17:14:41 <dlehman> wow, HAL? we still use that?
17:15:00 <adamw> dlehman: it's supposed to get un-used in f13, but it isn't yet
17:15:13 <adamw> xorg is still using it for setting up input devices right now (though they're working on that)
17:15:21 <adamw> but yeah, we're up to -7 in rawhide
17:15:26 <adamw> and i confirmed that -5 fixed the bug
17:15:33 <adamw> so let's close this
17:15:47 <adamw> #agreed 559679 is fixed, the fixed selinux-policy hit rawhide already; closing
17:16:12 <adamw> last bug!
17:16:14 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=560017
17:17:17 <dlehman> should be already taken care of, just not verified (except by me w/ a locally composed tree)
17:17:54 <adamw> is it committed / built?
17:18:00 <adamw> oh yeah, 13.25 is current right?
17:18:04 <dlehman> yes
17:18:05 <adamw> so action on jlaska to confirm the fix
17:18:06 <jlaska> I can retest using the current RATS drop as well
17:18:29 <jlaska> working some other RATS issues at the moment, so I'll probably poke it on Monday
17:18:41 <adamw> given dlehman's reproducer i'd agree this is a blocker
17:18:50 <adamw> so...it's a blocker, jlaska to confirm fix?
17:19:42 <jlaska> no objections
17:20:06 <adamw> #agreed 560017 is a blocker as per comment #3, it should be fixed, qa will confirm
17:20:11 <adamw> #action jlaska to confirm fix for 560017
17:20:28 <adamw> ...aaand we're done with the list
17:20:54 <adamw> quick troll through f13beta and f13blocker sound good?
17:21:00 <jlaska> let's dooeeet
17:21:19 <adamw> f13beta has three bugs, one of which we put on there today
17:21:25 * jlaska needs to train fingers to type F13 not F12
17:21:32 <adamw> #topic checking beta and final blocker bugs for any that should be promoted
17:21:45 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=558678 - I filed this and set it to beta blocker
17:21:48 <adamw> I think that's about right
17:22:23 <jlaska> seems appropriate
17:22:26 <adamw> although, actually, it doesn't really meet those criteria
17:23:18 <adamw> but we can talk about that at beta time
17:23:22 <adamw> right now, it doesn't need promoting to alpha
17:23:37 <jlaska> choice quote ... "It seems that previously-stored passwords are still working okay, but no new
17:23:40 <jlaska> ones can be written.
17:23:43 <jlaska> "
17:23:56 <adamw> the other beta one is another we just pushed from alpha
17:23:57 <adamw> so that's easy
17:25:56 <adamw> final list...https://bugzilla.redhat.com/showdependencytree.cgi?id=507681&hide_resolved=1
17:26:00 * jlaska pulls up f13blocker
17:26:05 <adamw> quite a few, so let's just eyeball it
17:26:48 <jlaska> what order you looking in?
17:27:45 <jlaska> 499902 sounds a bit heavy for a final release change
17:28:18 <adamw> yeah, but that's not this meeting
17:28:24 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=523646 seems icky
17:28:26 <adamw> also feels like a dupe to me
17:29:20 <jlaska> yuck
17:30:11 <adamw> just mentioned at the bottom which bug i think it's a dupe of
17:30:20 <adamw> if i'm right then it feels like a beta blocker to me, probably not alpha
17:30:22 <jlaska> k
17:30:42 <jlaska> who can make that determination?
17:31:01 <adamw> it's a 'how many systems does this affect' grey area
17:31:08 <adamw> so i think it still has to be a meeting judgment call
17:31:31 <jlaska> you're right, sorry though ... I meant, who can determine if it's a dup or not?
17:33:03 <adamw> oh. um, i usually just throw the question out and wait for an authoritative-sounding answer :P
17:33:14 <adamw> i guess ajax or mjg59 could
17:33:34 <adamw> i don't see anything else very scary on the list
17:33:35 <adamw> do you?
17:33:40 <jlaska> would it make sense to promote to Beta just in case?
17:33:43 <adamw> Tech33_away: do you have any particularly icky nouveau bugs on your radar?
17:33:58 <adamw> jlaska: maybe resolve the dupeness first. it's on my cc now so i won't lose it
17:34:34 <jlaska> adamw: k
17:35:02 <adamw> damn, he's away
17:35:08 <adamw> well, i'll check in with X triagers for next week
17:35:17 <adamw> i think we're pretty much done, then
17:35:31 <jlaska> that microcode_ctl one is icky, but seems fine for Final release
17:35:41 <jlaska> lots of kde stuff on the list, good to see
17:36:01 <jlaska> 531311 xen guest ...
17:36:15 <jlaska> I'm thinking that might hit point#13 on the beta release criteria
17:36:47 <adamw> oh yeah i was gonna ask about the microcode
17:37:06 <adamw> it's actually rather worse than described, on my system
17:37:09 <adamw> it blocks for about five minutes
17:37:15 <adamw> i wonder if it depends on how many cores you have, heh
17:37:32 <adamw> five minutes is past 'wow, this boot is slow' and into 'it's broken! help!' territory
17:37:39 <adamw> so we should probably commonbugs it for alpha, if it's not fixed
17:38:11 <jlaska> shall I keyword it?
17:38:28 <adamw> sure, thanks
17:39:51 <jlaska> trying to find out the virt host environment on 531311, but I think that lines up with our beta release criteria
17:40:05 <jlaska> I'll post to the bz
17:40:55 <adamw> ok, quick open floor segment
17:40:58 <adamw> #topic open floor
17:40:58 <jlaska> scratch that ... might not be an issue anymore
17:41:07 <adamw> anyone have any bugs to raise that we haven't considered so far?
17:41:57 <jlaska> nothing from me
17:42:07 <adamw> any of the other huge number of meeting participants?
17:42:37 <adamw> well then...beer time!
17:42:47 <jlaska> woah, you canadians live right :)
17:42:48 <adamw> #endmeeting