17:00:58 <tflink> #startmeeting f16-final-blocker-review-3
17:00:58 <zodbot> Meeting started Fri Oct 14 17:00:58 2011 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:11 <adamw> robatino: yeah, he's having trouble with the image generation due to grub changes
17:01:18 <tflink> #meetingname f16-final-blocker-review-3
17:01:18 <zodbot> The meeting name has been set to 'f16-final-blocker-review-3'
17:01:19 <adamw> tflink: ready as we'll ever be
17:01:24 <tflink> #topic roll call
17:01:34 * jdulaney is president
17:02:02 <jdulaney> Although rather distracted by external stimulii
17:02:28 <tflink> jdulaney: welcome, mr. president
17:02:39 <tflink> does that mean that you'll be running the meeting?
17:02:45 * brunowolff is here
17:02:55 <tflink> brunowolff: welcome
17:03:22 <jdulaney> tflink:  I'll pass
17:03:36 <jdulaney> A good president must delegate
17:03:36 <adamw> tough luck tim
17:03:40 * adamw will secretaryize
17:03:45 <adamw> unless anyone else wants to
17:04:38 * nirik is lurking. ping if I can help with anything.
17:04:47 * tflink was hoping that he could slack off :(
17:05:22 * jdulaney is going to look to see if there is a bug report already for the NM issues he is having with F16
17:05:30 <tflink> ok, let's get this party started
17:05:36 <tflink> #topic introduction
17:05:45 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:06:05 <tflink> we'll be working off of the blocker bug list on the wiki
17:06:13 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:06:33 <tflink> and roughly following the procedure listed
17:06:42 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:07:06 <tflink> #info 10 proposed blockers
17:07:14 <tflink> #info 4 proposed NTH
17:07:22 <tflink> #info 14 accepted blockers
17:07:37 <tflink> any objections to starting with the proposed blockers?
17:07:43 <adamw> go for it
17:07:49 <tflink> #topic (706756) No translation on Login-Page of the reboot-menu
17:07:49 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=706756
17:07:49 <tflink> #info Proposed Blocker, NEW
17:08:06 <tflink> no buggbot today?
17:08:32 <adamw> was it bugbot that was playing up and got kicked from a lot of channels?
17:08:48 <tflink> crap, maybe we should go with criteria change voting first
17:09:15 <adamw> we could decide whether to accept the current proposed criteria for the purpose of the meeting, yeah
17:09:35 <tflink> since the first bug hits the proposed i18n criteria
17:09:39 <tflink> #undo
17:09:39 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x850c790>
17:09:41 <tflink> #undo
17:09:41 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x850c7d0>
17:09:43 <tflink> #undo
17:09:43 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x850c710>
17:09:59 <tflink> #topic F16 Final Release Criteria Changes
17:10:23 <jdulaney> Ugh, no bug report for my issues, so more testing to figure out *what* is going on
17:10:44 <tflink> hrm, I seem to be typing faster than I'm thinking today
17:10:47 <tflink> #undo
17:10:47 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xf4f6810>
17:11:22 <tflink> #topic i18n criteria for Fedora 16 Final
17:11:36 <tflink> #info proposed criterion: The installer, bootup and login processes should correctly display all
17:12:14 <jdulaney> tflink:  I'm +1 for the new criterion; must run to the head
17:12:31 <tflink> any proposed changes to the wording?
17:12:54 <tflink> #link http://lists.fedoraproject.org/pipermail/test/2011-October/103588.html
17:13:16 <adamw> you cut off the proposed criterion?
17:13:30 <tflink> I did indeed
17:13:36 <tflink> #undo
17:13:36 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x57be950>
17:13:38 <tflink> #undo
17:13:38 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x8505190>
17:14:34 <tflink> #info proposed criterion: The installer, bootup and login processes should correctly display all translations that are available for use
17:14:42 <tflink> #link http://lists.fedoraproject.org/pipermail/test/2011-October/103588.html
17:15:15 <tflink> I'm also +1 on this
17:15:40 <tflink> so, any objections to accepting this criterion for final?
17:15:42 <adamw> it might wind up being too loose but i think it's okay for current purposes
17:15:57 <adamw> we might need to define 'vital' translations or something
17:16:04 <tflink> yeah, I can see it leading to a whole bunch of new blockers
17:16:23 <tflink> but we can cross that bridge if/when we get there
17:16:46 <adamw> k.
17:17:06 <jdulaney> I am returned
17:18:04 <jdulaney> I'm assuming that by 'available for use' means complete translations?
17:18:13 <tflink> proposed #agreed - "The installer, bootup and login processes should correctly display all translations available for use" is accepted as a release criterion for Fedora 16 Final
17:18:26 <adamw> jdulaney: oh, right, we intentionally don't use incomplete translations, right?
17:18:32 <adamw> maybe throw a 'sufficiently complete' in there
17:18:48 <jdulaney> Indeed
17:19:03 <tflink> proposed #agreed - "The installer, bootup and login processes should correctly display all sufficiently complete translations available for use" is accepted as a release criterion for Fedora 16 Final
17:19:10 <adamw> ack
17:19:15 <jdulaney> ack
17:19:24 <tflink> #agreed - "The installer, bootup and login processes should correctly display all sufficiently complete translations available for use" is accepted as a release criterion for Fedora 16 Final
17:19:41 <tflink> #topic Xen Criterion for Fedora 16 Final
17:20:16 <tflink> #info proposed criterion: The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0.
17:20:29 <tflink> #link http://lists.fedoraproject.org/pipermail/test/2011-October/103624.html
17:21:30 <jdulaney> I don't know enought about Xen to comment on this; looks good to me, though
17:21:38 <adamw> like i say my only worry with this is that a flat 'cloud providers' is something of a hostage to fortune, we might want to say 'widely used cloud providers' or smth.
17:21:48 <tflink> one suggestion was to change "cloud providers" to "widely used cloud providers"
17:21:52 <adamw> but other than that, yeah, i think we had good enough reasons.
17:22:18 <jdulaney> The cloud providers clause modification makes sense to me
17:22:51 <tflink> proposed #agreed - "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0." is accepted as a release criterion for Fedora 16 Final
17:23:04 <jdulaney> +1
17:23:46 <adamw> ack
17:23:53 <tflink> #agreed - "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0." is accepted as a release criterion for Fedora 16 Final
17:24:16 <tflink> I was going to leave the ks proposal alone since it doesn't affect final
17:24:46 <adamw> yeah, not so critical
17:25:28 <tflink> ok, lets get back to the bugs
17:25:43 <tflink> #topic (706756) No translation on Login-Page of the reboot-menu
17:25:44 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=706756
17:25:44 <tflink> #info Proposed Blocker, NEW
17:25:55 <adamw> so under our newly accepted criterion, +1 blocker.
17:26:02 <jdulaney> +1 blocker
17:26:14 <tflink> this one is pretty straight forward, the only reason it wasn't a blocker is due to pending criteria changes
17:26:42 <tflink> proposed #agreed - 706756 - AcceptedBlocker - The installer, bootup and login processes should correctly display all sufficiently complete translations available for use.
17:27:07 <jdulaney> ack
17:27:28 <adamw> ack
17:27:42 <tflink> #agreed - 706756 - AcceptedBlocker - The installer, bootup and login processes should correctly display all sufficiently complete translations available for use.
17:27:51 <tflink> #topic (737508) grub2 cannot install when /boot is md and first partition starts at sector 63
17:27:54 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=737508
17:27:56 <tflink> #info Proposed Blocker, NEW
17:28:20 <sgtpepper> I thought you could'nt put /boot in md anyway
17:29:18 <adamw> the beta RAID criterion specifically doesn't support it
17:29:46 <adamw> but final criterion says "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:30:03 <adamw> which leaves this a bit of a grey area, depending whether it's considered a 'workable partition layout'
17:30:15 <tflink> so is /boot on MD a workable layout?
17:30:28 <sgtpepper> In my opinion, never was
17:30:35 <sgtpepper> BIOS Raid is a different abstraction
17:30:37 <brunowolff> Existing systems may have /boot on raid 1 md raid.
17:30:47 <adamw> sgtpepper: md is linux software raid, as well as bios raid.
17:31:05 <adamw> i would like to have dlehman's input here
17:31:10 <adamw> but unfortunately he's off this week
17:31:43 <sgtpepper> I don't know about grub2... but grub always asked for a separate, garden variety, /boot partition
17:31:58 <sgtpepper> I might be wrong, since I never tried otherwise anyway
17:32:01 <sgtpepper> lol
17:32:08 <tflink> punt, then? I'm on the fence about blockery-ness
17:32:26 <tflink> ask for input from dlehman and re-visit next week?
17:32:33 <brunowolff> I run systems with linux software raid on /boot on most of my systems and it works just fine with grub.
17:32:36 <jdulaney> +1 for that
17:33:17 <sgtpepper> brunowolff: md raid? or BIOS Softraid?
17:33:27 <brunowolff> md raid.
17:33:34 <sgtpepper> ok, then beats me
17:33:35 <adamw> both can work.
17:33:44 <adamw> i've had /boot on an intel bios raid array before.
17:33:55 <adamw> but anyways - we kinda need anaconda team's call on this, so +1 punt.
17:34:02 <sgtpepper> punt
17:34:16 * jdulaney knows a punter
17:34:28 <jdulaney> Matt Dodge, punter for the Giants
17:34:29 <tflink> proposed #agreed - 737508 - We need input from the anaconda team to decide on blocker status, will ask for input and revisit next week
17:34:36 <jdulaney> ack
17:34:37 <sgtpepper> Never been a footbal guy
17:35:00 <jdulaney> Went to high school with him; his sisters are hot
17:35:14 <sgtpepper> lol
17:35:16 <adamw> do they know much about blocker bugs?
17:35:18 <adamw> ack
17:35:20 <tflink> #agreed - 737508 - We need input from the anaconda team to decide on blocker status, will ask for input and revisit next week
17:35:36 <tflink> #topic (742226) /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2
17:35:40 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742226
17:35:42 <tflink> #info Proposed Blocker, NEW
17:35:43 <jdulaney> adamw:  I doubt it
17:36:08 <tflink> looks like still no input from pjones
17:36:34 <tflink> but we have a new report from promise raid controller
17:36:39 <adamw> yeah. he's working on rhel issues atm.
17:36:46 <adamw> this one does keep looking worse, though.
17:37:21 * tflink is waiting until he can test serial console install with TC1 before pestering people for HW
17:37:47 <sgtpepper> tflink: I can try that on a vm
17:38:15 <tflink> sgtpepper: ok, I thought everything was pretty much fixed pending some grub changes
17:38:40 <sgtpepper> tflink: I can, haven't tried it yet
17:38:46 <adamw> i'm kinda shading towards taking this one as a blocker, given that more and more people seem to be hitting it
17:38:54 <tflink> same here
17:38:56 <jdulaney> Indeed
17:39:50 <tflink> proposed #agreed - 742226 - AcceptedBlocker - The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above
17:40:10 <tflink> ack/nak/patch?
17:40:30 <jdulaney> ack
17:40:35 <adamw> ack
17:40:45 <tflink> #agreed - 742226 - AcceptedBlocker - The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above
17:40:59 <tflink> #topic (743273) grub2 fails to install on IMSM raid device
17:40:59 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743273
17:40:59 <tflink> #info Proposed Blocker, NEW
17:41:26 <jdulaney> I'm leaning blocker on this one, too
17:41:30 <tflink> still missing data
17:41:30 <jdulaney> Same criterion
17:41:55 <sgtpepper> Its affecting too many people...
17:42:04 <tflink> this one?
17:42:11 <tflink> I only see one reporter
17:42:41 <adamw> yeah, this is only jes.
17:42:47 <adamw> well, except my bug looked like a dupe of it, didn't it?
17:42:54 <sgtpepper> 74226, 743273, all raid issues right?
17:43:25 <tflink> well, raid/grub/grub2/grubby
17:43:48 <tflink> I'm leaning towards rejecting if no new information by next week
17:43:59 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=744054
17:44:07 <adamw> sgtpepper: this is a different error message, different bug
17:44:14 <adamw> my report has the same error as jes', however
17:44:20 <sgtpepper> checking
17:45:27 <sgtpepper> adamw: yep
17:45:41 <adamw> unfortunately i can't do further testing as i needed my affected system to work so i converted it to soft raid.
17:45:59 <sgtpepper> let me do a simple test in a vm
17:46:03 <sgtpepper> with linux md
17:46:15 <sgtpepper> Fedora 16 Beta
17:46:18 <adamw> we can do that later...but for now i think we should probably mark these two as dupes and punt again...
17:46:25 <adamw> really need pjones to start looking at these
17:46:29 <tflink> yeah, sounds good
17:46:43 <jdulaney> +1
17:46:45 <sgtpepper> I'm really starting to hate virt-manager on F16
17:46:51 <sgtpepper> I need to file  a bug for that
17:47:12 <tflink> proposed #agreed - 743273 - Duplicate of 744054
17:47:42 <jdulaney> looks like I'll ACK
17:48:14 <tflink> or we could do it the other way around, I have no real preference
17:48:27 <adamw> sgtpepper: when it goes all non-responsive and you have to kill and restart it?
17:48:37 <sgtpepper> yes
17:48:37 <adamw> tflink: yeah
17:48:44 <adamw> sgtpepper: yeah i've been meaning to file a bug on that for weeks...
17:49:04 <sgtpepper> but before that, I've to restart libvirtd a couple of times to get it to connect+
17:50:00 <adamw> ack
17:50:03 <tflink> adamw: was that a "yes, duping the other is better"?
17:51:05 <tflink> #agreed - 743273 - Duplicate of 744054
17:51:17 <tflink> #topic (744054) Cannot install to MBR of an Intel BIOS RAID-0 array (Sony Vaio Z stock layout)
17:51:20 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=744054
17:51:21 <sgtpepper> adamw: after trying the raid stuff... I'll file the bug
17:51:22 <tflink> #info Proposed Blocker, NEW
17:51:25 <adamw> tflink: i've done it anyway
17:51:42 <adamw> so we can skip this one, it's now a dupe of 733273
17:51:45 <adamw> er 743273
17:51:52 <tflink> #agreed - 744054 - Still need more information on this, hopefully some dev input, will revisit next week
17:52:01 <tflink> #topic (745246) Need automatic conversion from grub1 to grub2 for all possible cases
17:52:04 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=745246
17:52:06 <tflink> #info Proposed Blocker, NEW
17:53:00 <adamw> i'm -1 on this; we only need scripts to assist yum upgrades which are unsupported, and booting still *works* after a yum update, we've tested that quite strongly now
17:53:12 <tflink> I'm -1 on this, we already have criteria for upgrades
17:53:26 <jdulaney> No LWN reader on Android market = suckage
17:54:03 <tflink> proposed #agreed - 745246 - RejectedBlocker - There are already release criteria that cover grub upgrades and yum is not a supported upgrade method
17:54:15 <sgtpepper> quick question... has anyone tried triggering the raid bug... Does the partition has to be somewhere in particular?
17:54:19 <jdulaney> I don't see the blockerness of this, anyway
17:54:36 <adamw> ack
17:54:38 <jdulaney> ack
17:55:03 <tflink> sgtpepper: I haven't tried the /boot on raid part but didn't have any other problems last time I isntalled with sw raid
17:55:10 <tflink> #agreed - 745246 - RejectedBlocker - There are already release criteria that cover grub upgrades and yum is not a supported upgrade method
17:55:17 <tflink> #topic (676488) update showing Error message ??? instead of actual error message
17:55:21 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=676488
17:55:23 <tflink> #info Proposed Blocker, NEW
17:55:36 <adamw> sgtpepper: it may be specific to certain intel bios raid setups.
17:55:59 <tflink> proposed #agreed - 676488 - AcceptedBlocker - The installer, bootup and login processes should correctly display all sufficiently complete translations available for use.
17:56:14 <sgtpepper> adamw: when you create a /boot device on an MD, anaconda warns
17:56:41 <adamw> yes.
17:57:02 <adamw> tflink: actually, my criterion as drafted doesn't cover this.
17:57:19 <jdulaney> Indeed
17:57:23 <tflink> good point
17:57:59 <adamw> we could extend it. or alternatively we could try to piggyback on the critical path definition, now i think about it
17:58:33 <tflink> it would make sense to extend it to default installs on blocking DE
17:59:17 <adamw> updates?
18:01:29 <adamw> so for the criterion text we could say "All critical path actions should correctly display all sufficiently complete translations available for use"
18:01:31 <tflink> Components included with live images and default installed systems (including installer, bootup and login processes) on release-blocking desktop environmentsshould correctly display all sufficiently complete translations available for use.
18:01:36 <adamw> with a link to the critpath policy
18:02:01 <adamw> that seems a bit too wide to me, we don't want to block on solitaire not displaying translations properly or something...
18:02:03 <tflink> I like adamw's better
18:02:21 <jdulaney> Indeed
18:02:41 <jdulaney> +1 for adamw's proposal
18:02:49 <adamw> "All critical path actions on release-blocking desktops should correctly display all sufficiently complete translations available for use"
18:02:59 <tflink> proposed #agreed - i18n release criteria changed to "All critical path actions should correctly display all sufficiently complete translations available for use"
18:03:11 <jdulaney> ack
18:03:27 <tflink> proposed #agreed - i18n release criteria changed to "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
18:03:35 <sgtpepper> as spanish speaker, I've to say +1
18:04:07 <adamw> ack
18:04:12 <jdulaney> ack
18:04:17 <tflink> #agreed - i18n release criteria changed to "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
18:05:04 <tflink> proposed #agreed - 646488 - All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use
18:05:18 <tflink> proposed #agreed - 646488 - AcceptedBlocker - All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use
18:05:35 <jdulaney> ack
18:06:20 <Cheshirc> what is a good way to check an updated package to see if it breaks anything ? (without koji)
18:06:33 <Cheshirc> install into mock ?
18:06:34 <adamw> ack
18:06:43 <tflink> #agreed - 646488 - AcceptedBlocker - All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use
18:06:48 <adamw> Cheshirc: or use a vm, i guess
18:06:56 <adamw> er, it's 676488
18:06:57 <tflink> #topic (741950) F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest
18:07:00 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741950
18:07:03 <tflink> #info Proposed Blocker, POST
18:07:13 <Cheshirc> heck , darn ... no vm here , yet
18:07:25 <tflink> this is going to be somewhat academic since it appears to have been fixed
18:07:38 <sgtpepper> Has anyone tried it since alpha?
18:07:57 * jdulaney doesn't use Xen
18:07:59 <tflink> yeah, earlier this week
18:08:00 <adamw> yeah, that konrad guy's been testing
18:08:05 <adamw> he said it's working now i think
18:08:15 <tflink> but I'm going to be -1 blocker on this, ironically
18:08:24 <tflink> it doesn't hit the new criterion
18:08:27 <adamw> how come?
18:08:35 <tflink> since this is about installing into a DomU, not running it
18:08:55 <jdulaney> Ooh
18:09:15 <tflink> unless we were including installation issues
18:09:34 <tflink> but you can build booting F16 xen guests w/ other tools like boxgrinder
18:09:39 <tflink> can/could
18:10:01 <tflink> although I'm splitting hairs a bit here
18:10:13 <sgtpepper> we're looking at final requirements right?
18:10:30 <tflink> yep, including the 2 we accepted during this meeting
18:11:06 <tflink> the criterion that this could hit is: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0."
18:11:16 <adamw> well i kinda expected we would be accepting installation issues
18:11:40 <sgtpepper> tflink: are those in the wiki? I'm looking at wiki/Fedora_16_Final_Release_Criteria
18:11:40 <tflink> yeah, I'm being too literal now that I'm looking at the beta release criteria for virt
18:11:47 <adamw> the existing kvm criteria are worded the same way but we've taken them to cover installation issues...
18:11:53 <adamw> sgtpepper: it's a new one so we didn't add it yet
18:12:03 <tflink> so +1 blocker
18:12:14 <adamw> we could change 'boot' to 'install and boot' i guess
18:12:24 <adamw> but yeah i'm +1 given how we've interpreted kvm issues historically
18:12:25 <tflink> proposed #agreed - 741950 - AcceptedBlocker - The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0.
18:12:27 <adamw> ack
18:12:30 <jdulaney> It seemds to me that install issues should be covered by default
18:12:45 <jdulaney> ack
18:12:49 <tflink> adamw: we have enough history with the kvm issues, I'm not too worried right now unless we want to clarify them
18:12:52 <adamw> i do have an action item to 'clarify' the virt critera after pjones pointed out some issues in the wording anyway
18:13:15 <tflink> jdulaney: well, maybe. one of the driving forces behind that criterion was EC2 and the other Xen based cloud providers
18:13:37 <tflink> and the methods I'm familiar with to create cloud images don't use anaconda
18:13:39 <sgtpepper> +1
18:13:49 <tflink> #agreed - 741950 - AcceptedBlocker - The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0.
18:14:02 <tflink> #topic (744641) system-setup-keyboard ignored KEYTABLE
18:14:02 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=744641
18:14:02 <tflink> #info Proposed Blocker, ON_QA
18:14:02 <adamw> tflink: yeah, that's worth considering. but hey, this one's fixed anyway so we can sleep sound. =)
18:14:42 <adamw> we'd need some info on the practical consequences here
18:14:58 <adamw> could this be the cause of the 'unlock screen with different layouts' bug?
18:15:09 <tflink> I was just wondering the same thing
18:15:20 <adamw> the commit identified as the culprit here is pretty old - feb 2010
18:15:28 <adamw> but then, someone did say the unlock bug happened in f15 too at least...
18:16:00 <jdulaney> Any reports in 13 or 14?
18:16:06 <adamw> propose we ask for info on the consequences and specifically ask about relationship to the unlock bug
18:16:19 <jdulaney> +1
18:16:29 <tflink> proposed #agreed - 744641 - We need more information on the practical impact of this bug before making a decision on blocker status
18:16:53 <tflink> the removal was committed in feb, could have made it into F15
18:17:10 <tflink> and there are updates for both F15 and F16
18:17:27 <tflink> so, my guess is that it did exist in F15, too
18:18:08 <tflink> ack/nak/patch?
18:18:09 <adamw> feb *2010*
18:18:16 <tflink> oh
18:18:17 <adamw> so it should have been in at least 13, 14, 15 too i believe
18:18:39 <jdulaney> Hence my asking about 13 and 14
18:18:42 <tflink> on a historical scale, 2011 and 2010 are practically the same thing :)
18:18:54 <sgtpepper> evolution 3.20 is nuts
18:19:11 <adamw> but ack
18:19:22 <jdulaney> ack
18:19:30 <tflink> #agreed - 744641 - We need more information on the practical impact of this bug before making a decision on blocker status
18:19:37 <tflink> #topic (743022) F15->F16 yum update fails with IMSM (BIOS) raid
18:19:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743022
18:19:37 <tflink> #info Proposed Blocker, NEW
18:20:14 <sgtpepper> -1 is the same case on grub => grub2 update
18:20:43 <tflink> I think that we were waiting to see if it could be reproduced w/ anaconda upgrade
18:21:20 <adamw> and for dev input, which again we still don't have
18:21:29 <sgtpepper> punt
18:23:03 <jdulaney> indeed
18:23:19 <adamw> ack
18:23:58 <tflink> I'm almost thinking -1 blocker on this but it looks like I'm outvoted
18:24:41 <tflink> incomplete report, lack of recent response from reporter, initial circumstances around hitting this are unsupported
18:24:54 <adamw> it doesn't really hurt to wait a bit longer though.
18:25:07 <tflink> proposed #agreed - 743022 - We still need dev input before making a decision on this, will revisit next week
18:25:12 <adamw> ack
18:25:33 <sgtpepper> tflink: I'll try to find a softraid 1 to test it... but no promises
18:26:10 <jdulaney> ack
18:26:38 <tflink> #agreed - 743022 - We still need dev input before making a decision on this, will revisit next week
18:26:55 <tflink> OK, that's it for the proposed blockers
18:27:03 <jdulaney> Yay
18:27:13 <jdulaney> Ponies!
18:27:16 <tflink> on to the proposed NTH
18:27:27 <sgtpepper> NTH?
18:27:27 <tflink> #topic (741538) f16 upgrade with encrypted rootfs: "The root for the previously installed system was not found".
18:27:30 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741538
18:27:33 <tflink> #info Proposed NTH, NEW
18:27:49 <tflink> sgtpepper: Nice to have, basically we would allow fixes past freeze but won't block release for them
18:28:25 <adamw> this seems like a clear nth candidate, it's a possible blocker, but we need anaconda team to decide what exactly's wrong
18:28:38 <sgtpepper> k
18:28:50 <jdulaney> Indeed
18:29:09 <jdulaney> +1 for NTH
18:30:09 <sgtpepper> +1
18:30:21 <adamw> +1
18:31:06 <tflink> proposed #agreed - 741538 - AcceptedNTH - need input from anaconda devs before considering for blocker due to failed upgrade of luks F15 system
18:31:11 <jdulaney> ack
18:33:19 <tflink> #agreed - 741538 - AcceptedNTH - need input from anaconda devs before considering for blocker due to failed upgrade of luks F15 system
18:33:30 <tflink> #topic (745711) virtio cannot transfer all guest anaconda logs to host
18:33:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=745711
18:33:36 <tflink> #info Proposed NTH, NEW
18:33:48 <tflink> this looks like a simple enough change, not sure why it has to be NTH
18:34:19 <adamw> "The only way to ensure this is going
18:34:19 <adamw> to make f16 is to have this accepted as a NTH"
18:34:24 <adamw> ales is still on that track. sigh.
18:34:32 * tflink wonders if hongqing has been able to test this
18:34:42 <adamw> so, again, anaconda's commit policies are not a reason to take bugs as nth or not. this doesn't seem to be significant enough to make nth.
18:34:59 <tflink> yeah, we can make our own images if needed for autoqa
18:35:03 <adamw> although there is hongqing's comment...
18:35:12 <adamw> but still, yeah, that's not enough reason to poke anaconda in a freeze.
18:35:17 <tflink> if this doesn't make F16 final, it isn't the end of hte world
18:35:53 <tflink> I'm thinking -1 NTH on this
18:36:10 <sgtpepper> ok, I've finally sent my introductory e-mail (despite evolution 3.2.0-1.fc16.x86_64)
18:36:17 <sgtpepper> tflink: agree
18:36:22 <tflink> I'd be OK with a new lorax build before freeze but not past freeze
18:36:24 <tflink> not for this
18:37:14 <sgtpepper> brb (smoke break)
18:37:43 <tflink> proposed #agreed - 745711 - RejectedNTH - This issue doesn't affect enough users to warrant taking a fix past freeze, the autoqa team is capable of building their own images if need be
18:37:56 <jdulaney> ack
18:37:58 <adamw> ack
18:38:06 <tflink> #agreed - 745711 - RejectedNTH - This issue doesn't affect enough users to warrant taking a fix past freeze, the autoqa team is capable of building their own images if need be
18:38:18 <tflink> #topic (745239) Missing/wrong menu entries
18:38:19 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=745239
18:38:19 <tflink> #info Proposed NTH, ON_QA
18:39:06 <tflink> I'm OK with NTH on this
18:39:23 <tflink> it can't be fixed post-release and seems to be isolated enough
18:39:55 <tflink> not sure why it's being proposed since it's already on_qa and we haven't hit freeze yet, though
18:40:44 <sgtpepper> tflink: I'd leave NTH since the update is already in qa
18:41:04 <tflink> sgtpepper: yeah, I'm not saying -1 NTH, just noting that it didn't need NTH status
18:41:40 <tflink> proposed #agreed - 745239 - AcceptedNTH - This can't be fixed post-release and the fix looks isolated to the security spin
18:41:47 <tflink> ack/nak/patch?
18:42:29 <sgtpepper> brb
18:42:36 <adamw> acl
18:42:37 <adamw> ack
18:43:04 <tflink> #agreed - 745239 - AcceptedNTH - This can't be fixed post-release and the fix looks isolated to the security spin
18:43:13 <tflink> #topic (735023) Fedora 16 live images are not EFI-capable: should use grub-efi package when available
18:43:16 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=735023
18:43:16 <tflink> this one, again
18:43:19 <tflink> #info Proposed NTH, ASSIGNED
18:44:27 <tflink> I'm still ~ -.5 NTH on this but I'm not going to fight it too much
18:45:00 <adamw> it's not fixable post-release and the only required change is to put grub-efi package on the live image, i tested that.
18:45:11 <adamw> anyway, we already committed the change, so it's rather academic =)
18:45:44 <tflink> yeah, I'm not objecting to the fix - just the idea of messing with grub related stuff post-release
18:46:05 <tflink> post-freeze, not post-release
18:46:19 <adamw> anyway, i think we can just change the bug to CLOSED and save the argument
18:46:37 <tflink> fair enough, we can revisit if any other issues come up
18:46:41 * adamw closes bug
18:47:14 <tflink> proposed #agreed - 735023 - close bug since fix has already been committed
18:47:22 <tflink> #agreed - 735023 - close bug since fix has already been committed
18:48:04 <tflink> and that would be all of the proposed NTH
18:48:14 <adamw> yay
18:48:33 <tflink> looks like there is only one accepted blocker to review
18:50:03 <tflink> nvm, make that 6
18:50:13 <adamw> one, six, easy mistake to make ;)
18:50:26 <tflink> within an order of magnatude
18:50:55 <tflink> #topic (722963) TypeError: %d format: a number is required, not str
18:51:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=722963
18:51:10 <tflink> #info Accepted Blocker, Modified
18:51:31 <tflink> we're still waiting for jdulaney to verify this one
18:51:54 <adamw> that slacker. =(
18:51:55 <adamw> =)
18:52:12 <adamw> but yeah, not much to do here. we can poke him again and if he doesn't get to it, just close it.
18:52:37 <sgtpepper> its hard to hit it accidentally for what I'm reading
18:53:02 <tflink> #agreed - 722963 - still waiting for testing, needinfo reporter again
18:53:24 <tflink> #topic (728301) F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown filesystem
18:53:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=728301
18:53:54 <tflink> wait, why did I do this one?
18:54:06 <tflink> bah
18:54:10 <tflink> #undo
18:54:11 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x45c7550>
18:54:12 <tflink> #undo
18:54:12 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xbd52a90>
18:54:35 <tflink> #topic (740062) fcoe.py fails to detect FCoE NIC due to extraneous newline character
18:54:40 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=740062
18:54:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=740062
18:54:56 <tflink> #info Accepted Blocker, Modified
18:55:24 <adamw> so this will just be a needsretesting with tc1
18:55:41 <tflink> yep
18:55:53 <adamw> nothin' much else to see, move along
18:56:04 <tflink> #agreed - 740062 - This will need retesting with Final TC1
18:56:31 <tflink> #topic (741817) DispatchError: Can not reschedule step 'bootloader' from 'skipped' to 'requested'
18:56:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=741817
18:56:45 <tflink> #info Accepted Blocker, MODIFIED
18:57:08 <adamw> i'll re-test this with tc1
18:57:26 <tflink> #agreed - 741817 - Retest with Final TC1
18:57:33 <tflink> adamw: wasn't this fixed with beta?
18:57:52 <adamw> fix is marked as 16.21
18:57:54 <tflink> eh, doesn't matter
18:58:00 <tflink> I thought that beta was 16.21
18:58:11 <adamw> nup
18:58:29 <tflink> #topic (743381) anaconda should install grub-efi when doing an EFI install
18:58:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=743381
18:58:42 <tflink> #info Accepted Blocker, ON_QA
18:59:05 <tflink> #agreed - 743381 - Needs re-testing with TC1
18:59:28 <adamw> the update marked as fixing this doesn't fix it, that was an error, but i think it should be fixed in anaconda for tc1
18:59:38 <adamw> so yeah, re-test
18:59:41 <tflink> #topic (736893) New Install of Fedora 16 TC1 on iBFT iSCSI NIC fails on first reboot
18:59:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=736893
19:00:03 <tflink> crap, this is another ASSIGNED one
19:00:09 <tflink> not sure what I was looking at
19:00:21 <sgtpepper> ha! checkmate Mr. Evolution
19:00:27 <tflink> #undo
19:00:27 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x6947090>
19:00:29 <tflink> #undo
19:00:29 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x10407250>
19:00:37 <tflink> ok, are there any bugs that I missed?
19:00:59 <tflink> #topic Open Discussion
19:01:05 <sgtpepper> tflink: I don't think so.. I'd all the tabs opened of firefox
19:01:55 <adamw> tflink: er, i don't see why we wouldn't review ASSIGNED open blockers.
19:02:00 <tflink> yep, and no additions to the tracker bugs since the lists were generated
19:02:26 <tflink> adamw: oh, I thought the idea was just >= MODIFIED
19:02:31 <adamw> why?
19:02:36 <adamw> they're the ones least likely to need any review
19:02:49 <sgtpepper> just checking... Have you received my Hello World e-mail?
19:02:51 <adamw> the ones that need review are the ones that aren't fixed yet, so we can make sure steps are going to get taken to fix them =)
19:02:52 <adamw> sgtpepper: yes.
19:02:58 <sgtpepper> amgreat!
19:03:02 <adamw> twice.
19:03:15 <tflink> ah, so  <MODIFIED, then
19:03:15 <sgtpepper> hmm.. yep.. I know why, sorry about that
19:04:05 <tflink> #undo
19:04:05 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x939b090>
19:04:08 <tflink> #topic (736268) [abrt] GConf2-3.1.90-1.fc16: Process /usr/bin/gsettings-data-convert was killed by signal 11 (SIGSEGV)
19:04:11 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=736268
19:04:14 <tflink> #info Accepted Blocker, NEW
19:04:20 <adamw> tflink: basically, we should check all blockers. =)
19:05:02 <adamw> haven't seen this one in a long time
19:05:07 <adamw> and i just checked abrt-gui and don't have any reports of it
19:05:11 <adamw> i think it's probably fixed
19:05:27 <adamw> close it and ask people to re-open if they still see it?
19:05:58 <sgtpepper> tflink: I'd the same
19:06:15 <sgtpepper> Its still on the latest update-testing
19:06:19 <tflink> proposed #agreed - 736268 - There haven't been any reports of this in a while, close and ask to re-open if it resurfaces
19:06:55 <adamw> ack
19:07:05 <tflink> #agreed - 736268 - There haven't been any reports of this in a while, close and ask to re-open if it resurfaces
19:07:15 <tflink> #topic (722963) TypeError: %d format: a number is required, not str
19:07:15 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=722963
19:07:15 <tflink> #info Accepted Blocker, MODIFIED
19:07:30 <tflink> curse me for doing these all out of order
19:07:32 <tflink> #undo
19:07:32 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x939bf90>
19:07:34 <tflink> #undo
19:07:34 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x939be10>
19:07:35 <tflink> #undo
19:07:35 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x939b250>
19:07:46 <tflink> #topic (728301) F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown filesystem
19:07:49 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=728301
19:07:51 <tflink> #info Accepted Blocker, ASSIGNED
19:08:37 <tflink> again, close and ask to re-open if they hit it again?
19:09:00 <adamw> no, i don't think so.
19:09:09 <adamw> i see no indication that anyone did any work to fix it, and dave says it's easily reproducible.
19:09:25 <adamw> it's not a hugely common configuration so i'm not horribly surprised we don't have extra reporters.
19:09:31 <sgtpepper> hmm... want me to try to reproduce it?
19:09:56 <sgtpepper> I've a few cycles
19:09:58 <adamw> i think it'd be better to poke anaconda team at this point.
19:10:29 <tflink> proposed #agreed - 728301 - Need information from anaconda team
19:11:52 <adamw> ack
19:11:59 <sgtpepper> ack
19:12:03 <tflink> #agreed - 728301 - Need information from anaconda team
19:12:31 <tflink> #topic (743281) Disk encryption with national keymap doesn't work
19:12:31 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743281
19:12:32 <tflink> #info Accepted Blocker, NEW
19:13:31 <tflink> this looks ok for now, adamw added a comment about the s-s-k bug
19:13:33 <sgtpepper> its only with national keymap or any keymap besides us
19:13:33 <adamw> well, we have the potential s-s-k cause here
19:13:39 <adamw> not much other movement though
19:14:18 <tflink> proposed #agreed - 744641 - need retesting with potential s-s-k fix
19:15:22 <adamw> ack
19:15:26 <sgtpepper> ack
19:15:38 <tflink> #agreed - 744641 - need retesting with potential s-s-k fix
19:16:03 <tflink> #topic (736893) New Install of Fedora 16 TC1 on iBFT iSCSI NIC fails on first reboot
19:16:07 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=736893
19:16:09 <tflink> #info Accepted Blocker, ASSIGNED
19:17:15 <sgtpepper> engage dracut team
19:17:33 <tflink> proposed #agreed - 736893 - Need information and/or retesting from reporter
19:18:04 <adamw> yeah, we need to poke reporter again
19:18:26 <tflink> #agreed - 736893 - Need information and/or retesting from reporter
19:18:54 <tflink> #topic (740625) After update to 3.1.92, can't submit password on login window
19:18:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=740625
19:18:59 <tflink> #info Accepted Blocker, ASSIGNED
19:19:55 <tflink> not quite sure about this one
19:20:08 <tflink> sounds like there's activity, though. I'd say leave it alone
19:20:36 <adamw> yeah, it looks like charles' issue is quite clear and has logs provided, so i think this is on desktop team
19:20:52 <adamw> ""yum remove gdm-fingerprint-plugin" solves the problem for me."
19:21:49 <tflink> proposed #agreed - 740625 - There seems to be progress on this issue, no poking is needed
19:21:51 <adamw> ack
19:22:22 <tflink> #agreed - 740625 - There seems to be progress on this issue, no poking is needed
19:22:53 <tflink> that's right, he did clone it as mclasen requested
19:22:58 <tflink> #topic (746132) After update to 3.1.92, can't submit password on login window
19:23:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=746132
19:23:04 <tflink> #info Accepted Blocker, NEW
19:23:47 <adamw> we should close this one back as a dupe i think
19:24:04 <sgtpepper> dupe
19:24:04 <adamw> i agreed with charles that 740625 should stay open as it was charles who reported that one in the first place, it's really been for his bug all along
19:24:24 <tflink> proposed #agreed - 746132 - close as dupe of 740625
19:24:33 <sgtpepper> wait...
19:24:33 <adamw> (and when someone asks for a new bug so the history of the old one will be cleared out, cloning the old bug is hardly any use anyway :>)
19:24:34 <adamw> ack
19:24:43 <sgtpepper> quick question
19:24:54 <sgtpepper> the first bug asked to open a new bug because history got mixed up
19:24:55 <tflink> #agreed - 746132 - close as dupe of 740625
19:25:02 <sgtpepper> should we close the first one or second one?
19:25:11 <tflink> #topic (738092) swell-foop blank screen
19:25:11 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=738092
19:25:11 <tflink> #info Accepted Blocker, NEW
19:25:17 <adamw> sgtpepper: the second one.
19:25:52 <adamw> hum, comment #6 looks useful
19:25:56 <adamw> guess we should re-assign to cogl
19:26:18 <tflink> proposed #agreed - 738092 - reassign to cogl so that it gets rebuilt
19:26:22 <adamw> ack
19:26:43 <jsmith> ACK
19:26:43 <tflink> #agreed - 738092 - reassign to cogl so that it gets rebuilt
19:26:52 <tflink> #topic (732164) grub version in f16 beta does not detect md devices properly
19:26:55 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=732164
19:26:57 <tflink> #info Accepted Blocker, NEW
19:26:57 <adamw> oh hey it's the acking station
19:27:21 <tflink> sounds like we might be able to close this
19:27:46 <adamw> hum
19:27:52 <adamw> this actually looks like my/jes' bug
19:27:56 <tflink> proposed #agreed - 732164 - appears to have been fixed. retest with TC1, close if fixed
19:28:39 <jsmith> adamw: I'm sneaky like that :-)
19:29:40 <adamw> hum, yeah, you're right, not quite the same
19:30:05 <adamw> i think just close it as the reporter said 1.99 would fix it
19:30:41 <tflink> he does?
19:31:00 <adamw> yeah
19:31:04 <tflink> I don't see that? I just see "fixed with some combination of X-Z"
19:31:13 <adamw> that's a different person with a different bug.
19:31:22 <adamw> from the initial report: "please upgrade grub2 to 1.99 final or pull in the fix from upstream to make it
19:31:22 <adamw> possible to have /boot on a md mirror. the setup is working now with grub 1.99
19:31:23 <adamw> final without any additional patches."
19:32:54 <tflink> that's part of the error message from grub2, no?
19:34:24 <adamw> no.
19:34:39 <tflink> nvm, but that's still a request to update grub2, not a statement that it was fixed in fedora
19:34:55 <adamw> well sure, but the request in the bug is for us to push 1.99 final, and we did.
19:35:11 <tflink> ok
19:35:42 <tflink> proposed #agreed - 732164 - This should be fixed in some grub2 update, close bug
19:36:12 <tflink> #agreed - 732164 - This should be fixed in some grub2 update, close bug
19:36:18 <tflink> #topic (743386) Ensure grub2 and grub-efi are both on the install media without making them 'default' in comps
19:36:21 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=743386
19:36:24 <tflink> #info Accepted Blocker, NEW
19:37:03 <tflink> proposed #agreed - 743386 - Progress is being made on this for TC1, needs testing once TC1 is released
19:37:14 <adamw> it should be fixed in tc1, we can set modified.
19:37:28 <tflink> proposed #agreed - 743386 - Progress is being made on this for TC1, needs testing once TC1 is released. Set to modified
19:38:14 <adamw> ack
19:38:23 <tflink> #agreed - 743386 - Progress is being made on this for TC1, needs testing once TC1 is released. Set to modified
19:38:28 <tflink> #topic (730985) Customizing panel objects / layout with 'Alt + Right Click' not working
19:38:32 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=730985
19:38:34 <tflink> #info Accepted Blocker, NEW
19:39:36 <tflink> is this still a blocker since it only happens on VMs?
19:40:21 <adamw> eh, borderline
19:40:28 <adamw> probably shades it to nth for me
19:40:37 <adamw> it can be fixed post-release and it's a 'polish' criterion
19:41:02 <sgtpepper> basic functionality works... I'd go with NTH
19:42:12 <tflink> proposed #agreed - 730985 - RejectedBlocker, AcceptedNTH - Since this only affects VMs, it it doesn't directly hit any release criteria, demoting to NTH
19:42:51 <tflink> ack/nak/patch?
19:43:47 <adamw> well, it hits the criteria, but only on certain configurations
19:43:56 <adamw> and we're making a judgment call that the impact is sufficiently limited to downgrade
19:44:26 <jsmith> NTH works for me
19:45:10 <tflink> proposed #agreed - 730985 - RejectedBlocker, AcceptedNTH - Since this only affects VMs, we are making the judgement call that the impact is sufficiently limited to downgrade this to NTH
19:45:13 <adamw> ack
19:45:38 <tflink> #agreed - 730985 - RejectedBlocker, AcceptedNTH - Since this only affects VMs, we are making the judgement call that the impact is sufficiently limited to downgrade this to NTH
19:45:53 <tflink> alrighty, I think we're actually done this time :-)
19:46:25 <tflink> #topic Open Discussion
19:46:30 <adamw> yay
19:46:32 <tflink> Any other topics?
19:46:49 <tflink> adamw: are you updating the release criteria page w/ the new blockers?
19:47:19 <adamw> i will do, yeah
19:47:52 <tflink> #action adamw will update the F16 final release criteria page with new criteria
19:48:19 * tflink sets the fuse for 2 minutes if there are no other topics
19:49:11 <tflink> #info next blocker bug review meeting: 2011-10-21 @ 17:00 UTC
19:50:29 <tflink> OK everyone, thanks for coming!
19:50:37 * tflink will send out minutes later today
19:50:40 <tflink> #endmeeting