17:04:36 <tflink> #startmeeting f17-final-blocker-review-meeting-5
17:04:36 <zodbot> Meeting started Fri May 11 17:04:36 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:04:44 <tflink> #meetingname f17-final-blocker-review-meeting-5
17:04:44 <zodbot> The meeting name has been set to 'f17-final-blocker-review-meeting-5'
17:04:49 <tflink> #topic roll call
17:04:58 <tflink> who all's here for some blocker meeting awesomeness?
17:05:01 <cmurf> MrJones go to your bug, insert F17Blocker in the Blocks field, that will propose it as a blocker bug.
17:05:20 <tflink> MrJones: 752650
17:06:40 <MrJones> it seems  I cannot enter F17Blocker for https://bugzilla.redhat.com/show_bug.cgi?id=797455 (which is not my own bug, but somethhing that happens for me with TC4/live cd aswell)
17:06:42 <buggbot> Bug 797455: unspecified, unspecified, ---, dracut-maint, NEW, dracut: Partial mode. Incomplete logical volumes Unable to process initqueue
17:06:45 <tflink> this is gonna be a real short meeting if nobody else is here ...
17:07:13 * brunowolff is here
17:07:27 <cmurf> MrJones no, go to YOUR bug.
17:07:37 <brunowolff> A short meeting would be good though as I need to mow my lawn,
17:07:48 <MrJones> cmurf: since I suppose mine is fixed in alpha, I guess it is not a good idea to propose it as a blocker
17:07:55 <tflink> yeah, I need to be out of here in ~ 3 hours
17:08:13 <tflink> looking at the list, I'm unsure that 3 hours is going to be enough
17:08:15 <cmurf> MrJones: That's why I suggested you dd TC4 to a stick first.
17:08:27 <MrJones> ok but what about the dracut one?
17:08:28 * tflink wonders if we should start doing 2 of these per week instead of one
17:08:34 <MrJones> that one is a pretty nasty bug too..
17:08:44 <cmurf> tflink i'm here, i'll vote
17:08:45 <akshayvyas> tflink: 3 hours O:-)
17:08:58 <cmurf> but not 3 hours this time
17:09:23 <tflink> MrJones: there isn't nearly enough information on that one to consider it as a blocker
17:09:48 <tflink> MrJones: one log file from 3 months ago isn't recent enough
17:09:56 <MrJones> tflink: but it definitely happens to me too... with TC4. so it's not fixed, and still happening
17:10:05 <MrJones> I can try to gather more logs if someone tells me what to do
17:10:12 <tflink> cmurf: we could go longer than 3 hours if you'd like
17:10:21 <cmurf> tflink negative
17:10:38 <tflink> akshayvyas: welcome to the party!
17:10:57 <akshayvyas> tflink: hope we enjoy :P
17:11:44 <cmurf> MrJones http://fedoraproject.org/wiki/How_to_debug_Dracut_problems
17:11:46 <tflink> akshayvyas: of course we will, how could you question the fun ....
17:12:24 <akshayvyas> tflink: well you will when its filled with bugs
17:12:40 <tflink> MrJones: search for dracut debugging - you should find a fedora wiki page with instructions on what to do for gathering dracut bug data
17:13:02 <tflink> MrJones: sorry I'm not more help at the moment - trying to get this meeting started
17:13:14 <MrJones> np, the wiki page should help
17:13:33 <tflink> ok, we have 2, maybe 3 people
17:13:42 <tflink> shall we attempt to get started?
17:13:57 <akshayvyas> is adamw here ??
17:14:31 <tflink> nope, he's ... elsewhere. to be honest, I'm not sure where. something about traveling
17:14:45 <cmurf> tflink: golf
17:14:56 <akshayvyas> okzz
17:15:20 <akshayvyas> so just 3
17:15:31 <tflink> I think that brunowolff is here
17:15:48 <tflink> and I see a couple others who I imagine are lurking, waiting for specific issues :)
17:15:59 <tflink> #topic Introduction
17:16:12 <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:16:21 <brunowolff> Yeah, I'm here
17:16:31 <tflink> We'll be following the process outlined at:
17:16:32 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:16:32 <tflink> The bugs up for review today is available at:
17:16:32 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:16:32 <tflink> The criteria for release blocking bugs can be found at:
17:16:34 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
17:16:36 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:16:39 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
17:16:59 <tflink> can you tell that I have that written out, ready for copy-paste?
17:17:17 <tflink> ... I mean ... I really can type that fast :)
17:17:36 <tflink> anyways, objections to starting with the proposed blockers
17:17:38 <tflink> ?
17:18:08 <cmurf> proceed
17:18:28 <tflink> #topic (821015) Software Update claims all packages are untrusted
17:18:28 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=821015
17:18:28 <tflink> #info Proposed Blocker, MODIFIED
17:18:29 <buggbot> Bug 821015: high, unspecified, ---, nphilipp, MODIFIED, Software Update claims all packages are untrusted
17:19:24 <cmurf> Alpha criterion 20
17:19:33 <tflink> as written, I'm +1 blocker on this
17:19:42 <tflink> "#topic (821015) Software Update claims all packages are untrusted
17:19:42 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=821015
17:19:42 <tflink> #info Proposed Blocker, MODIFIED
17:19:43 <buggbot> Bug 821015: high, unspecified, ---, nphilipp, MODIFIED, Software Update claims all packages are untrusted
17:19:46 <tflink> crap
17:19:49 <tflink> #undo
17:19:49 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x296366d0>
17:19:51 <tflink> #undo
17:19:51 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x23150b10>
17:20:34 <cmurf> From a practical point of view, I'm +1, but I'm not seeing a basis off hand for this in release criterion.
17:21:05 <cmurf> Alpha criterion 20 says "system must be able to download and install updates"
17:21:08 <tflink> it hits 'The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops' for systems where the user doesn't have the root password
17:21:22 <brunowolff> This seems to be two separate bugs. One is needing root access to do an update and the other is there is a bogus trust message.
17:21:51 <tflink> brunowolff: I thought that needing root access to install untrusted packages was normal and desired behavior
17:22:00 <brunowolff> Assuming policy is that you don't need to be root to update packages, I think that part of the bug is a blocker.
17:22:09 <akshayvyas> well c#3 submitted as an update
17:22:23 <cmurf> I think you need to be root to update packages.
17:23:13 <tflink> not from trusted repos if you're using pk, I don't think
17:23:18 <cmurf> One of these is obviously a security problem: you can't have non-root doing updates, while the updates are also untrustworthy. That's not a good best practices combination, regardless of release criteria.
17:23:35 <akshayvyas> can i run yum update from normal user ??
17:23:41 <brunowolff> OK, so that packages being untrusted is what leads to needing to be root. I'm +1 blocker on this. It's a bit borderline, since probably end users will have the root password.
17:23:49 <tflink> cmurf: also outside the scope of what we're trying to do here
17:24:11 <tflink> akshayvyas: no, but IIRC you can run updated using the graphical pk without admin privelages
17:24:17 <brunowolff> But since there is a fix, and it is definitely (IMO) NTH, either way I think we want to pull this fix.
17:24:41 <cmurf> I am +1 on NTH, 0 on blocker
17:24:46 <akshayvyas> tflink: yeah true so i am +1
17:24:50 <tflink> +1 blocker
17:25:38 <tflink> proposed #agreed - 821015 - AcceptedBlocker - Violates the F17 alpha release criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" for systems where the user doesn't have the root password
17:26:10 <cmurf> ack
17:26:11 <akshayvyas> ack
17:26:26 <brunowolff> ack
17:26:38 <tflink> #agreed - 821015 - AcceptedBlocker - Violates the F17 alpha release criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" for systems where the user doesn't have the root password
17:26:53 <tflink> #topic (819113) abrt-ccpp service not enabled by default on F17
17:26:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=819113
17:26:53 <tflink> #info Proposed Blocker, VERIFIED
17:26:54 <buggbot> Bug 819113: unspecified, unspecified, ---, abrt-devel-list, VERIFIED, abrt-ccpp service not enabled by default on F17
17:27:16 * nirik arrives late.
17:28:07 <cmurf> +1 NTH, -1 blocker
17:28:08 <akshayvyas> well i am -1 blocker
17:28:08 <tflink> nirik: better late than never :-D
17:29:04 <brunowolff> +1 NTH -1 blocker
17:29:05 * nirik is def +1NTH... borderline +1 blocker too...
17:29:28 <tflink> yeah, the only criterion that comes close is about installer issues, which aren't affected by abrt-ccpp
17:30:03 <nirik> yeah, so I guess NTH is fine.
17:30:20 <brunowolff> It can be fixed in an update except for live images. And the value of dumps from the gold live images will decrease over time.
17:30:25 <tflink> proposd #agreed - RejectedBlocker, AcceptedNTH - While this doesn't hit any of the release criteria, losing crash reports is not something that we want to be doing and would take a well tested fix
17:30:31 <akshayvyas> ack
17:30:34 <cmurf> ack
17:30:34 <nirik> brunowolff: good point.
17:30:35 <nirik> ack
17:30:35 <brunowolff> ack
17:30:48 <tflink> #agreed - RejectedBlocker, AcceptedNTH - While this doesn't hit any of the release criteria, losing crash reports is not something that we want to be doing and would take a well tested fix
17:31:12 <tflink> #info according to the author, this fix has been in F16 stable for some time now
17:31:27 <tflink> #topic (813548) alsa bug makes kernel kill pulseaudio sometimes
17:31:27 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=813548
17:31:27 <tflink> #info Proposed Blocker, NEW
17:31:28 <buggbot> Bug 813548: unspecified, unspecified, ---, jkysela, NEW, alsa bug makes kernel kill pulseaudio sometimes
17:31:52 <tflink> hrm, I suppose that I chould #chair someone in case I get disconnected ... any volunteers?
17:32:22 <nirik> I think I might be seeing this or something like it here... it's weird.
17:32:49 <cmurf> -1
17:33:10 <l1m3> Halp! Also, hi
17:33:31 <nirik> anyhow, there's not much info on this, I would say defer and keep gathering info. It doesn't seem like a blocker at the moment due to not many people hitting it and being able to fix post release.
17:33:47 <cmurf> I'm fine leaving it proposed
17:33:53 <akshayvyas> well i am -1 blocker
17:34:20 <tflink> this has been open for a while, so I'm leaning more towards -1 blocker
17:34:23 <brunowolff> That's my take too. It seems rare enough that we don't want to block on this.
17:34:52 * nirik is fine with -1 blocker, but if a solution comes up later it might be nth
17:35:08 <cmurf> i'm definitely -1 blocker at this point, but it just got switched over to alsa component today from (I think) kernel
17:35:10 <brunowolff> There have been other audio complaints on the lists, but I don't know if they are from the same bug.
17:35:19 <cmurf> So all the more reason it's probably not a blocker
17:35:49 <cmurf> It'd be fixable with an update.
17:36:00 <akshayvyas> cmurf: +1
17:36:07 * cmurf is being a hard ass on blockers today, I want F17 to ship!
17:36:45 <tflink> proposed #agreed 813548 - RejectedBlocker  - While somewhat ugly, this bug seems to be a corner case that only affects a few users and would be fixable with an update for installed systems.
17:36:51 <akshayvyas> ack
17:36:52 <nirik> ack
17:36:53 <cmurf> ack
17:36:53 <brunowolff> ack
17:37:00 <tflink> #agreed 813548 - RejectedBlocker  - While somewhat ugly, this bug seems to be a corner case that only affects a few users and would be fixable with an update for installed systems.
17:37:12 <tflink> #topic (816742) Installer in EFI mode needs to use grub2 and allow /boot on LVM
17:37:15 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816742
17:37:16 <buggbot> Bug 816742: unspecified, unspecified, ---, anaconda-maint-list, NEW, Installer in EFI mode needs to use grub2 and allow /boot on LVM
17:37:17 <tflink> #info Proposed Blocker, NEW
17:37:22 <tflink> this'll be a quick one, I think
17:37:22 <cmurf> low lag today, nice
17:37:34 <tflink> cmurf: from me or bugzilla?
17:37:43 <cmurf> freenode
17:38:23 <cmurf> so about 816742, i'm not understanding...this is just, not going to happen. The EFI patches in Grub Legacy aren't in GRUB2 yet, so ...
17:38:28 <cmurf> this is just untenable
17:38:35 <tflink> I'm -1 blocker -1 nth on this
17:38:44 * nirik is also -1, -1
17:38:50 <nirik> cmurf: right.
17:38:57 <cmurf> -1, -1
17:39:16 <akshayvyas> -1
17:39:27 <tflink> no more grub changes unless ABSOLUTELY needed - as in > 50% of users' systems are exploding into flames and grub is the only place we can fix it ...
17:39:37 <tflink> my vote, anyways
17:39:41 <nirik> yeah
17:40:04 <cmurf> tflink seriously
17:40:54 <tflink> proposed #agreed - 816742 - RejectedBlocker, RejectedNTH - This doesn't hit any of the release criteria - it is well known that grub2-efi is not ready for use. No NTH because it is too late to take grub changes that aren't accepted as blockers
17:41:06 <akshayvyas> ack
17:41:27 <brunowolff> ack
17:41:58 <nirik> ack
17:42:08 <tflink> #agreed - 816742 - RejectedBlocker, RejectedNTH - This doesn't hit any of the release criteria - it is well known that grub2-efi is not ready for use. No NTH because it is too late to take grub changes that aren't accepted as blockers
17:42:20 <tflink> #topic (817037) Installer damage Disks
17:42:21 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=817037
17:42:21 <tflink> #info Proposed Blocker, NEW
17:42:22 <buggbot> Bug 817037: high, unspecified, ---, anaconda-maint-list, NEW, Installer damage Disks
17:43:03 <cmurf> this is next to incoherent
17:43:52 * nirik reads. It looks like we don't have a reliable reproducer.
17:44:25 <nirik> or it could be pilot error.
17:44:28 <tflink> this sounds like user error to me
17:44:31 <nirik> anyhow, -1 blocker at this time
17:44:35 <cmurf> -1 -1
17:44:38 <brunowolff> -1 blocker -1 NTH
17:44:44 <tflink> selecting 'use all space' will blank all available disks
17:44:46 <akshayvyas> tflink : sure it is
17:45:15 <akshayvyas> well i am -1 blocker
17:45:36 <tflink> proposed #agreed - 817037 - RejectedBlocker, RejectedNTH - There is no clear reproducer and it is not clear that this isn
17:45:58 <akshayvyas> ack
17:46:14 <tflink> proposed #agreed - 817037 - RejectedBlocker, RejectedNTH - There is no clear reproducer and it is not clear that this isn't expected behavior (autopart with 'use all space' is supposed to clear off all disks')
17:46:20 <cmurf> ack
17:46:29 <nirik> ack
17:46:50 <tflink> #agreed - 817037 - RejectedBlocker, RejectedNTH - There is no clear reproducer and it is not clear that this isn't expected behavior (autopart with 'use all space' is supposed to clear off all disks')
17:47:04 <tflink> #topic (820366) Cannot boot 17 Beta installer: /dev/root does not exist
17:47:08 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820366
17:47:09 <buggbot> Bug 820366: high, unspecified, ---, anaconda-maint-list, NEW, Cannot boot 17 Beta installer: /dev/root does not exist
17:47:10 <tflink> #info Proposed Blocker, NEW
17:47:42 <cmurf> Umm, why are people two days ago filing bugs on beta??
17:47:50 <cmurf> Is this just me being a dick or is this a WTF moment?
17:48:08 <cmurf> -1
17:48:12 <nirik> they switched to tc4 when asked.
17:48:18 <MrJones> well beta is still on the homepage... probably people didn't know there is tc4
17:48:25 <MrJones> I did the same mistake
17:48:42 <nirik> still not much info here to decide with.
17:48:47 <cmurf> OK so I'm sorta being a dick.
17:49:10 <akshayvyas> okay its tested by tflink so im surely -1 blocker
17:49:22 <cmurf> There's also a lot of PXE changes since beta.
17:49:27 <tflink> that ks arg doesn't look right to me
17:50:15 <cmurf> tflink this sounds an awful lot like last week's PXE blocker proposal where it was failing to mount or find the repo
17:50:18 <tflink> akshayvyas: assuming that I didn't screw up my test, anyways
17:51:01 <akshayvyas> tflink: i am not sure on this as he fllowed the same
17:51:42 * nirik would prefer to punt this one and have several people retest pxe/nfs
17:51:43 <tflink> the obvious difference that I can see is that he is grabbing ks over nfs instead of http like I am
17:52:04 <tflink> either way, there isn't enough data to take this as a blocker
17:52:06 <cmurf> fair point
17:52:14 <cmurf> i'm fine leaving it proposed
17:52:21 * tflink is ok with punting for a week
17:52:36 <cmurf> +1 punt
17:53:01 <nirik> yeah.
17:53:23 <tflink> proposed #agreed - 820366 - There is not enough information to decide on whether or not this is actually a blocker - ask for more information and more re-testing of PXE (and ks delivery over nfs)
17:53:31 <cmurf> ack
17:53:34 <tflink> proposed #agreed - 820366 - There is not enough information to decide on whether or not this is actually a blocker - ask for more information and more re-testing of PXE and ks delivery over nfs
17:53:34 <akshayvyas> ack
17:53:48 <nirik> ack
17:54:06 <tflink> #agreed - 820366 - There is not enough information to decide on whether or not this is actually a blocker - ask for more information and more re-testing of PXE and ks delivery over nfs
17:54:21 <tflink> #topic (813648) gnome-shell shows blank windows on hardware lacking NPOT textures
17:54:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=813648
17:54:25 <buggbot> Bug 813648: high, unspecified, ---, pbrobinson, MODIFIED, gnome-shell shows blank windows on hardware lacking NPOT textures
17:54:26 <tflink> #info Proposed Blocker, MODIFIED
17:55:20 <cmurf> +1
17:55:44 <akshayvyas> +1 blocker
17:56:18 <cmurf> fix is either done or near done, blacklisting is a regression
17:56:25 <nirik> +1blocker
17:57:03 <tflink> it sounds like there are still text display issues, though
17:57:06 <tflink> or am I missing something
17:57:28 <cmurf> yes there are, hence blocker until it is fixed. alternative is blacklisting.
17:57:49 * nirik looks at 745202
17:58:20 <cmurf> ben wants it fixed so i think it'll get fixed
17:58:36 * nirik is a bit confused...
17:58:38 <akshayvyas> i dont see any comment after update
17:59:12 <nirik> "but after I logged on my session displayed the gnome shell very well" then 2 comments later: "The text in the panels and some dialog boxes is still scrambled."
17:59:56 <nirik> ah, I see.
18:00:11 <nirik> NV34 is still going to be blacklisted for those text issues.
18:00:13 <cmurf> Yeah this bug is FX.
18:00:20 <cmurf> NV3x is still blacklisted for text.
18:00:30 <nirik> right, so yeah, +1blocker still
18:00:51 <cmurf> And there's a lot of FX hardware out there, so +1 blocker.
18:01:12 <tflink> yeah, this is a regression in how clutter was handling a limitation in the older nvidia - separate from the NV34 text issue
18:01:15 <akshayvyas> +1 blocker
18:01:18 <tflink> +1 blocker
18:01:27 <brunowolff> +1 blocker
18:02:53 * tflink is not seeing an obvious criterion
18:03:11 <nirik> get to desktop and apply updates/
18:03:12 <nirik> ?
18:03:45 <cmurf> alpha 17
18:03:47 <tflink> "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use "?
18:04:03 <cmurf> after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention.
18:04:21 <tflink> eh, mine's pushing intention
18:06:07 * tflink is starting to think NTH instead
18:06:48 <cmurf> I approve of the conservative approach on this.
18:07:36 <tflink> I just can't see holding release if this was the only bug left
18:07:45 <cmurf> Actually GeForce FX = NV3X = GeForce 5
18:08:16 <akshayvyas> well this one is hardware specific bug
18:08:37 <tflink> yeah, but a non-insignificant amount of hardware, I think
18:08:46 <cmurf> tflink yeah, I agree, and to be consistent with hard ass friday, I'll switch to +1 NTH and 0 on blocker.
18:08:49 * tflink wishes he had the smolt data in front of him
18:09:03 <cmurf> 0 instead of -1 because there's a lot of FX hardware floating around. While not exactly current...
18:09:06 <akshayvyas> +1 NTH
18:09:23 <tflink> so we're +3/-1 blocker and +3 NTH?
18:09:47 <cmurf> Wait. NVIDIA dropped support for the FX series.
18:09:51 <cmurf> so I'm -1 blocker
18:09:54 <cmurf> +1 NTH
18:09:57 <aspratyush> +1 NTH
18:10:11 <tflink> so we're +4/-2 blocker and +4 NTH (forgot adam
18:10:19 <cmurf> I mean, if nvidia has dropped it, i think it's overly aggressive to consider this a blocker.
18:10:39 <tflink> the only reason to take it as a blocker is that it can't be fixed as an update for livecds
18:10:47 <cmurf> oh well
18:10:53 <cmurf> NTH
18:11:25 <tflink> yeah, clearly nth - not so clear on blocker
18:11:30 <cmurf> what about netinst.iso?
18:11:31 <brunowolff> It could make it more important, since you have to use Nouveau. It's possible that for the nvidia driver this issue doesn't show up. (We don't know based on what's in the bug.)
18:12:01 <cmurf> this is a gnome specific problem right?
18:12:08 <cmurf> gnome+nouveau
18:12:50 <tflink> brunowolff: good point - there is no mention of the driver used
18:14:18 <cmurf> This is a cogl issue, which gnome-shell uses. So I'm pretty sure DVD and netinst and maybe even KDE would be fine.
18:14:20 <brunowolff> I think it is implied that they used Nouveau, but we don't know if it would also happen with nvidia.
18:14:39 <tflink> yeah, I was assuming nouveau
18:14:48 <brunowolff> Given that there appears to be a fix the difference between blocker and NTH is small.
18:15:23 <nirik> yeah, was just going to say that. I'm still ok with blocker since we have a fix in hand and this hardware type could be popular...
18:15:29 * tflink is slightly worried about consistency  - there has been quite a bit of grumbling about the 16bpp change
18:16:03 <tflink> which are not related to this bug other than effects - graphical glitches in the non-majority of users
18:16:11 <cmurf> oh really, there's a 16bpc compositing being done now?
18:16:21 <tflink> cmurf: a bug from beta
18:16:48 <tflink> brunowolff: did I miss your vote?
18:17:42 * tflink prefers to have a 3 vote difference to take as blocker
18:18:02 <tflink> but will leave as proposed blocker and accepted nth if we don't get another vote soon
18:18:37 <cmurf> punt on blocker, accepted NTH?
18:19:32 <tflink> proposed #agreed - 813648 - AcceptedNTH - This is a graphical issue that would affect a minority of users  - there is unclear cosensus on whether or not this is enough to be a final blocker (can't fix livecds with an update) but enough for NTH.
18:20:01 <akshayvyas> ack
18:20:08 <aspratyush> ack
18:20:48 <nirik> ack I suppose. ;)
18:21:05 <tflink> nirik: unless we can get another vote for blocker
18:21:36 <nirik> yeah, thats fine.
18:21:39 <tflink> #agreed - 813648 - AcceptedNTH - This is a graphical issue that would affect a minority of users  - there is unclear cosensus on whether or not this is enough to be a final blocker (can't fix livecds with an update) but enough for NTH.
18:22:01 <tflink> #topic (801650) Fedora PV guest 17 fails to boot under Xen (with SandyBridge or newer hardware that do xsave)
18:22:04 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=801650
18:22:05 <tflink> ah, a fun one
18:22:06 <buggbot> Bug 801650: high, high, ---, law, MODIFIED, Fedora PV guest 17 fails to boot under Xen (with SandyBridge or newer hardware that do xsave)
18:22:08 <tflink> #info Proposed Blocker, MODIFIED
18:24:10 <cmurf> -1
18:24:28 <tflink> I'm definitely +1 NTH on this, leaning +1 blocker
18:24:38 <akshayvyas> i am not sure, is xen still working
18:24:41 <tflink> it really depends on whether or not this affects cloud providers like EC2
18:25:41 <brunowolff> Sorry I had to step away for a bit. I was +1 blocker on the last one, but would be OK with +1 NTH given there is a fix.
18:25:43 <nirik> yeah, amazon uses xen
18:25:46 <nirik> +1 blocker
18:26:01 <cmurf> Looks like it's a violation of Final criterion 11
18:26:05 <tflink> I haven't read the whole thing in detail but it sounds like there is some feature that is only partially implemented in SB and SB-EP
18:26:15 <nirik> but unclear what hw
18:26:47 <tflink> the only caveat is that the criteria does NOT affect Dom0
18:27:08 <tflink> and I'm not clear what the bug is here - whether the issue is with the Dom0 or DomUs
18:27:28 <nirik> its sandybridge dom0 with any f17 domU
18:27:45 <nirik> I have no idea how common sandybridge dom0's are.
18:29:12 <nirik> so, I'm a slight +1 blocker... but if everyone says NTH, ok by me too
18:29:36 <akshayvyas> +1 blocker
18:29:46 <cmurf> -1
18:30:02 <cmurf> the domu is working, and that's required by criterion
18:30:17 <cmurf> the dom0 is what was not working (it seems) and there's a fix
18:30:52 <cmurf> +1 NTH, and either punt on blocker for more info or -1 blocker
18:30:53 <tflink> yeah, I'm pretty much in the same boat. definite +1 NTH, leaning towards +1 blocker
18:31:06 <nirik> cmurf: I read it the other way?
18:31:09 * nirik re-reads
18:31:31 <nirik> yeah, dom0 working, domU not?
18:31:32 <cmurf> comment 56, domu is booting
18:31:47 <tflink> I read it as the Dom0 passing through something that the DomUs can't quite handle when Dom0 is SB, SB-EP or some AMD
18:31:54 <cmurf> yeah
18:32:13 <cmurf> but the domu boots successfully
18:32:21 <tflink> which covers a little too much HW for me to be comfortable with rejecting
18:32:22 <nirik> with the fix, yes
18:33:20 <cmurf> nirik: good point, it's not clear to me that F17 boots in a xen domu without the fix.
18:33:27 <cmurf> If it doesn't, it's clearly a blocker.
18:33:40 <tflink> it sounds like we're slightly +1 blocker
18:33:59 <akshayvyas> i am still +1 blocker
18:34:24 <tflink> I'd like to wait until the issue talked about in c#67 is resolved before taking a build, though
18:34:25 <cmurf> Need info
18:34:47 <tflink> especially since we're talking about a fixed-by-new-glibc blocker bug here
18:35:01 <nirik> tflink: see next comment
18:35:08 <nirik> it was a testing issue.
18:35:19 <cmurf> I want an update to c67 and I want to know if without the glibc fix, if F17 boots in a xen domu, *and* if not, if it's only a Sandy Bridge issue.
18:35:20 <tflink> oh, there's a new comment? I opened the link a while ago
18:35:32 <nirik> see c68. ;)
18:36:15 <tflink> there is indeed a new comment
18:36:38 <tflink> I'm reading pretty unanimous NTH on this
18:36:53 <cmurf> Ok I still want to know if without new glibc if F17 boots in a xen domU and if it doesn't, if it's restricted to Sandy Bridge.
18:36:53 * nirik is still +1 blocker
18:36:59 <tflink> and +2/-1/+2slight on blocker
18:37:10 <cmurf> I would not +1 blocker domU failure on Sandy Bridge only CPUs.
18:37:31 <nirik> cmurf: yes, thats my reading of it... domU fails on sandy bridge cpus.
18:37:35 <tflink> cmurf: keep in mind that EC2 is xen and the AMIs are only spun up once per release
18:37:56 <nirik> we don't have much data on how many dom0 sandybridge cpus are used out there.
18:38:11 <akshayvyas> nirik: +1
18:38:17 <tflink> so if amazon does have a bunch of SB/SB-EP/affected AMD boxes, we have a bunch of noworky AMIs
18:38:31 <nirik> but I know ibm is just pushing server hardware with them... so amazon could well buy some of those.
18:38:46 <cmurf> oh boy
18:38:47 * tflink thinks that amazon builds their own boxes
18:39:03 <nirik> could be. no idea at all.
18:39:17 <cmurf> I mean you really think of holding up a whole release for just one chip?
18:39:32 <cmurf> There's no possible way to get it working after release?
18:39:39 <tflink> isn't not just one chip
18:39:48 <nirik> cmurf: no, because that would need new install images.
18:39:51 <cmurf> Sandy Bridge = 1 chip in my present vernacular
18:40:08 <tflink> it is 2 specifically named, newer platforms and another platform FAMILY that isn't as explicitly mentioned
18:40:26 <tflink> SB, SB-EP and some (newer?) AMD
18:40:54 <cmurf> it certainly appears to meet the final criterion #11
18:41:01 <tflink> c#42
18:41:44 <cmurf> OK so Sandy Bridge and an  unspecified AMD
18:41:55 <tflink> SB and SB-EP are not quite the same thing
18:41:57 <cmurf> I'm a 0 on blocker, +1 NTH
18:42:04 <cmurf> what's the vote?
18:42:14 <nirik> +1 blocker, +1 NTH
18:42:25 <tflink> which puts us at +2/+2slight/1x(+/-0) on blocker
18:42:29 <tflink> unanimous NTH
18:42:33 <nirik> adamw is weak +1
18:42:37 <nirik> in the bug
18:42:52 <cmurf> so you have +3 even if it's a weak +3
18:42:54 <tflink> nirik: yeah, he and I are the +2 slight
18:43:14 <nirik> ok
18:43:19 <cmurf> it's a plus 3 :-) weak or strong doesn't matter
18:44:23 <tflink> proposed #agreed - 801650 - AcceptedBlocker, AcceptedNTH - Violates the F17 final release criterion "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" for some newer platforms
18:44:28 <cmurf> ack
18:44:51 <akshayvyas> ack
18:45:00 <nirik> ack
18:45:12 <tflink> #agreed - 801650 - AcceptedBlocker, AcceptedNTH - Violates the F17 final release criterion "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" for some newer platforms
18:45:25 <cmurf> actually you had +4 nirik+tflink+adamw+akshayvyas
18:45:46 <tflink> cmurf: that's not how I think of it
18:46:15 <tflink> I like to see a 3 vote separation between +1 and -1, slight in my mind is +/- .5
18:46:22 <cmurf> LOL
18:46:25 <tflink> #topic (819492) GVfs apps should convey when eject/unmount takes a long time
18:46:28 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=819492
18:46:29 <cmurf> I'm using integers
18:46:30 <buggbot> Bug 819492: unspecified, unspecified, ---, tbzatek, NEW, GVfs apps should convey when eject/unmount takes a long time
18:46:31 <tflink> #info Proposed Blocker, NEW
18:46:42 <tflink> cmurf: I see that
18:46:44 <tflink> :)
18:46:53 <cmurf> "weak" tells me you want more convincing
18:47:27 <tflink> I can't speak for adam but my "slight +1" is thinking the issue is important but being somewhat worried about what other bugs the fix could bring
18:47:43 <cmurf> tflink: well yeah, new glibc this late in the game...
18:47:49 <tflink> exactly
18:47:58 <tflink> but we digress
18:48:15 <cmurf> however, if it fixes a one time image for xen,and breaks a handful of stuff that we don't find in RC, those things can probably be fixed with an update.
18:50:29 <nirik> so, this is a anoying bug. I also can see the various sides of it. It's also unclear to me what the fix might be... if we hold release it could be a looooong time to get something implemented.
18:52:29 <cmurf> comment 19
18:52:34 <cmurf> this is not exactly true
18:52:40 <brunowolff> The criteria allows for documenting the issue in common bugs.
18:52:42 <cmurf> Windows will tell you when it's safe to remove the device.
18:52:53 <cmurf> Mac OS will tell you after the fact that you removed the device too soon.
18:53:08 <tflink> brunowolff: true but I don't think that most people read commonbugs ... and this is a data-eating issue
18:53:37 <akshayvyas> i am clearly +1 blocker as i faced the same thing
18:53:43 * jsmith leans toward calling it a blocker too
18:53:51 <aspratyush> +1 blocker here too
18:53:57 <cmurf> This needs to go to FESCo in my opinion.
18:54:12 <cmurf> This is a significant ideological issue, it doesn't match up with any release criterion I'm finding.
18:54:28 <tflink> kparal is +1, desktop team is -1, adam is +/- 0
18:54:49 <akshayvyas> cmurf: yeah agree
18:54:50 <cmurf> Haha, so this happens with Gnome but not KDE?
18:55:09 <tflink> cmurf: "All known bugs that can cause corruption of user data must be fixed or documented at Common F17 bugs"
18:55:14 <nirik> well, I don't know that we are going to have a solution in the timeframe that we want... there is lots of talk about 'design' and 'reimplement'
18:55:42 * nirik is a weak -1 blocker, +1 NTH if something can be made to work, and document in common bugs and release notes.
18:55:51 <brunowolff> Is this a regression from F16?
18:55:58 <cmurf> tflink: not a bug as far as desktop is concerned
18:56:11 <tflink> yeah, c#10 talks about a new API for udisks2
18:56:16 <cmurf> tflink: and it might cause corruption, it's questionable when this happens.
18:56:16 <aspratyush> yup
18:56:29 <brunowolff> If F16 had the same problem and we haven't been getting a lot of reports of this, I'd feel better about releasing with it just documented.
18:56:43 <cmurf> -1 blocker
18:56:45 <cmurf> -1 NTH
18:56:47 <tflink> I think that there was a somewhat working warning in F16
18:56:57 <jsmith> Yeah, I've seen the warning in F16
18:57:02 <aspratyush> F16 shows up the warning
18:57:21 <nirik> brunowolff: yes
18:57:21 <tflink> why was the warning removed before any kind of replacement was available?
18:57:54 <cmurf> desktop didn't like the code
18:58:13 <nirik> I think implementations switched to a newer one that didn't do that.
18:58:15 * nirik looks.
18:58:15 <cmurf> I'm not sure if this is Fedora desktop or Gnom upstream
18:58:23 <nirik> udisks to udisks2?
18:58:54 <aspratyush> a hack, but which prevents data corruption, is a too important a feature to be missed
18:59:45 <cmurf> well I'm amused desktop doesn't think this is a GVFS bug. So if they're going to deny responsibility for it and yet there's cases of data corruption...
19:00:11 <jsmith> cmurf: I'm tempted to think the same thing, but I don't have all the details -- so I'm going to withhold judgment for the time being
19:00:12 <tflink> I didn't see anywhere that thought this wasn't a bug
19:00:22 <tflink> just not in gvfs
19:00:55 <tflink> well, we seem rather devided on the issue. let's start with NTH before we go to blocker
19:00:58 <cmurf> tflink: DZ says it's "all in the apps using [GVfs]"
19:01:00 <tflink> divided
19:01:37 <cmurf> tflink: it isn't going to happen even as NTH, that's clear, they don't have a time frame for dealing with this in F17 at all.
19:02:26 <tflink> I'm counting +2/-1 nth thus far
19:02:32 <cmurf> If it's not a bug, fine, I'll consider it bad design and still write it up in Common Bugs. And then create a new FESCo ticket.
19:02:59 <cmurf> I'll = I'd
19:03:00 <tflink> I'm hesitantly +1 NTH
19:03:41 <tflink> with the caveat that NTH != we'll take anything - I'd want to see testing etc. before accepting and no last minute fixes
19:03:45 <cmurf> I'll change my vote +1 NTH as a political message, even though I know it's pointless.
19:04:07 <tflink> then we're NTH without question
19:04:49 <cmurf> yes
19:05:28 <cmurf> considering comment 15. i love this line by Kamil: "If you ever intended to get a terrible reputation for losing your users' data, removing notifications is a great way to go."
19:05:40 <tflink> proposed #agreed - 819492 - AcceptedNTH - This is a potentially nasty bug that could lead to user data corruption/loss. Well tested fixes will be considered past freeze but probably not at the last minute.
19:05:53 <tflink> note that doesn't mean anything about blocker status, just looking at NTH right now
19:06:00 <cmurf> ack
19:06:07 <nirik> ack
19:06:10 <akshayvyas> ack
19:06:24 <aspratyush> ack
19:06:25 <tflink> #agreed - 819492 - AcceptedNTH - This is a potentially nasty bug that could lead to user data corruption/loss. Well tested fixes will be considered past freeze but probably not at the last minute.
19:06:30 <tflink> ok, now on to blocker
19:06:47 <tflink> I see +1, +0 from the bug
19:07:02 <tflink> -1.5 in here
19:07:02 <aspratyush> am still +1 blocker
19:07:12 <tflink> +1/-1.5 here
19:07:25 <tflink> oh, -1 from the desktop team
19:07:35 <cmurf> Desktop team says it's not a bug, therefore it's a not a blocker. What release criteria?
19:07:51 * nirik is weak -1 blocker. I think documenting and perhaps a workaround would be great, but I don't think we can wait for a full proper fix to be designed.
19:07:53 <tflink> so total +2/-2.5/2x(+/- 0)
19:07:55 <cmurf> They deny this bug is even a bug.
19:08:24 <tflink> nirik: yeah, you're the -.5 of -2.5 :)
19:08:28 <brunowolff> I'm similar to nirik. -1 blocker, but would like to see some mitigation of this for the release.
19:08:49 * nirik nods.
19:08:59 <cmurf> I think we need to use either -1, 0 or +1. The finer granularity delays decisions.
19:09:03 * tflink is +1 blocker on the issue but agrees that waiting for a full, proper fix is silly
19:09:28 <aspratyush> "something" before release is needed
19:09:29 <cmurf> propose punt on blocker, and to write up a FESCo ticket.
19:10:13 <tflink> one approach that we could take is to take this as a blocker as long as there is no mitigation
19:10:30 <brunowolff> I think that is a reasonable proposal.
19:10:33 <tflink> so we would revoke blocker status if certain criteria were met
19:10:51 <tflink> brunowolff: the fesco ticket or making the blocker status conditional?
19:11:07 <brunowolff> Conditional blocker status.
19:11:17 <cmurf> tflink i think the certain criteria needs to go to FESCo. So if that is tied to a blocker vote I will vote +1.
19:11:37 <tflink> cmurf: filing something with FESCo is orthagonal to blocker status
19:12:13 <cmurf> i'm tying my vote to it
19:12:42 <cmurf> otherwise i'm a -1 because according to the maintainers, this is not a bug
19:13:06 <tflink> proposed #agreed - 819492 - AcceptedBlocker (conditional) - The situation as is has been decided to be a blocker issue but we recognize that a full, proper fix is not practical and would agree to remove blocker status once some work was done to mitigate the poential for users to lose data
19:13:16 <tflink> ack/nak/patch?
19:13:20 <akshayvyas> ack
19:13:23 <aspratyush> ack
19:13:57 <brunowolff> ack
19:14:00 <tflink> if anyone has suggestions on how to word that better, I'm listening :)
19:14:17 <cmurf> ack
19:15:07 <tflink> nirik: any thoughts on the proposal?
19:15:17 <nirik> I guess that sounds ok, I don't know how likely a mitigation is either. ;)
19:15:45 <tflink> we can cross that bridge if/when we get there - hopefully this doesn't turn into a game of "chicken", though
19:16:07 <tflink> since there really isn't anything QA can do about this at the end of the day except for make noise
19:16:17 <tflink> #agreed - 819492 - AcceptedBlocker (conditional) - The situation as is has been decided to be a blocker issue but we recognize that a full, proper fix is not practical and would agree to remove blocker status once some work was done to mitigate the poential for users to lose data
19:16:37 <nirik> yeah
19:17:07 <tflink> cmurf: are you planning to raise the issue with FESCo?
19:17:54 <nirik> you're welcome to, not sure fesco can do much, but possibly find folks willing to work more on a mitigation I suppose.
19:18:09 <tflink> #info cmurf proposed raising this issue with fesco
19:18:36 <tflink> cmurf: unless you'd like to see more details in the minutes
19:18:42 <cmurf> I'll bring it up with Kamil
19:18:58 <tflink> ok
19:18:59 * j_dulaney waves
19:19:07 <tflink> any objections to moving on to the next issue?
19:19:13 <tflink> j_dulaney: you missed all the fun bugs
19:19:27 * j_dulaney was asleep
19:19:37 <j_dulaney> School's out for summer
19:20:49 * j_dulaney looks through the blocker list
19:20:53 * tflink assumes silence == no objections
19:21:02 <tflink> #topic (811412) F17 Final TC3 has bogus OS X entries in grub2 when installed from dd-written images
19:21:04 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=811412
19:21:06 <buggbot> Bug 811412: urgent, unspecified, ---, hedayatv, MODIFIED, F17 Final TC3 has bogus OS X entries in grub2 when installed from dd-written images
19:21:07 <tflink> #info Proposed Blocker, MODIFIED
19:22:13 <tflink> I need to leave in about 30 minutes or so - unless someone else is willing to take over running the meeting, we'll be wrapping up about then
19:22:50 <nirik> +1 NTH, not sure it's a blocker
19:23:10 <cmurf> -1
19:23:17 <cmurf> -1 NTH, -1 blocker
19:23:22 <akshayvyas> i dont think its a blocker
19:23:28 <cmurf> No criterion.
19:23:28 <j_dulaney> +1 blocker
19:23:35 <akshayvyas> -1 blocker
19:23:42 <cmurf> And OS X remains bootable, just not through the grub menu.
19:23:50 <aspratyush> -1 blocker
19:24:25 <jsmith> -1 blocker, +1 NTH
19:24:39 * j_dulaney changes to -1 blocker, +1 NTH
19:24:55 <j_dulaney> I didn't realize it was a slightly different bug at by this point
19:25:23 * j_dulaney should read *all* the comments, not just the couple at the top
19:26:03 <brunowolff> -1 blocker, +1 NTH
19:26:33 <cmurf> NTH based on what criterion?
19:26:48 <j_dulaney> It's ugly
19:26:51 <cmurf> We don't have any criterion that relates to Mac OS X at all.
19:27:04 <akshayvyas> cmurf: +1
19:27:59 <cmurf> There's no basis for block or NTH.
19:28:26 * cmurf is a Mac user, currently using Colloquy on Mac OS.
19:29:00 * nirik looks.
19:29:39 <nirik> it doesn't need to hit critera for NTH?
19:29:43 <tflink> NTH would be that it's ugly and potentially confusing to have non-functional boot entries on non-OS X machines
19:29:45 * nirik thinks it just looks bad and we have a fix.
19:30:07 <jsmith> nirik: No, I don't think it does.
19:30:23 <nirik> right, so I'm still +1 NTH
19:30:24 <j_dulaney> cmurf:  https://fedoraproject.org/wiki/QA:SOP_nth_bug_process
19:30:37 <brunowolff> NTH is something that can't easily be fixed in an update or that would block if it was KDE or Gnome, but instead affects another desktop.
19:30:39 <tflink> no, we don't need to hit criteria for NTH
19:30:52 <tflink> +1 NTH
19:31:11 <tflink> it sounds like we're pretty much RejectedBlocker, AcceptedNTH
19:31:13 * jsmith is still +1 NTH as well
19:32:02 <j_dulaney> tflink:  +1
19:32:12 <j_dulaney> tflink:  time for a proposed?
19:32:25 <cmurf> ok i missed that this is happening on non-Mac OS systems
19:32:27 <cmurf> +1
19:32:30 <cmurf> NTH
19:32:40 <tflink> proposed #agreed - 811412 - RejectedBlocker, AcceptedNTH - This doesn't hit any of the release criteria and doesn't seem release critical but it looks bad and could cause confusion. thus a well tested fix would be accepted
19:32:46 <cmurf> ack
19:32:47 <j_dulaney> ack
19:32:48 <akshayvyas> ack
19:32:49 <brunowolff> ack
19:32:50 <jsmith> ACK
19:32:51 <nirik> ack
19:32:56 <tflink> j_dulaney: sorry, used to working at home - not used to hearing conversations around me :)
19:33:08 <tflink> #agreed - 811412 - RejectedBlocker, AcceptedNTH - This doesn't hit any of the release criteria and doesn't seem release critical but it looks bad and could cause confusion. thus a well tested fix would be accepted
19:33:10 <j_dulaney> tflink:  Indeed
19:33:22 <tflink> #topic (820971) Help -> Content function is broken
19:33:23 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820971
19:33:23 <tflink> #info Proposed Blocker, NEW
19:33:24 <buggbot> Bug 820971: unspecified, unspecified, ---, metherid, NEW, Help -> Content function is broken
19:34:02 <tflink> yay! an easy one
19:34:13 <tflink> clear blocker - violates "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:34:28 <nirik> yeah. blocker +1
19:34:29 <cmurf> +1
19:34:33 <aspratyush> +1
19:34:43 <tflink> proposed #agreed - 820971 - AcceptedBlocker - Violates the F17 final release criterion "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:34:45 <j_dulaney> +1 blocker for this and 820973
19:34:48 <cmurf> final release #16
19:34:50 <j_dulaney> ack
19:34:57 <brunowolff> ack
19:34:59 <nirik> ack
19:35:01 <aspratyush> ack
19:35:05 <akshayvyas> ack
19:35:12 <tflink> it amuses me that we block release for this and not for the USB bug - I understand but it sounds odd from a certain point of view
19:35:23 <nirik> yeah.
19:35:25 <tflink> #agreed - 820971 - AcceptedBlocker - Violates the F17 final release criterion "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:35:32 <nirik> on some levels tho, this should be a simple fix...
19:35:34 <cmurf> ack
19:35:35 <nirik> the other one... who knows.
19:35:58 <j_dulaney> nirik:  The other looks to be the same
19:36:11 * tflink shakes his fist at pragmatism
19:36:14 <tflink> #topic (740280) /dev/live no longer exists
19:36:15 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=740280
19:36:15 <tflink> #info Proposed Blocker, VERIFIED
19:36:16 <buggbot> Bug 740280: unspecified, unspecified, ---, kanarip, VERIFIED, /dev/live no longer exists
19:36:42 <nirik> -1 blocker, +1 NTH
19:37:06 <tflink> same; -1 blocker, +1 NTH
19:37:39 <j_dulaney> -1 blocker, +1 nth
19:37:48 <akshayvyas> -1 blocker, +1 NTH
19:38:02 <cmurf> -1, +1
19:38:14 <tflink> proposed #agreed - 740280 - RejectedBlocker, AcceptedNTH - None of the F17 release requirements mention persistance in live images and thus this isn't a blocker. However, it is a significant feature that we would like to see working before release and a tested fix would be considered for accepting past freeze
19:38:18 <j_dulaney> ack
19:38:21 <tflink> ack/nak/patch?
19:38:21 <aspratyush> ack
19:38:33 <akshayvyas> ack
19:38:41 <nirik> ack
19:38:54 <tflink> #agreed - 740280 - RejectedBlocker, AcceptedNTH - None of the F17 release requirements mention persistance in live images and thus this isn't a blocker. However, it is a significant feature that we would like to see working before release and a tested fix would be considered for accepting past freeze
19:38:55 <cmurf> ack
19:38:59 <tflink> #topic (820750) TC4 live install to HD  fails on first try - Partition(s) 1 on /dev/sda have been written, but we have been unable to inform the kernel of the change
19:39:02 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820750
19:39:03 <buggbot> Bug 820750: high, unspecified, ---, kanarip, NEW, TC4 live install to HD  fails on first try - Partition(s) 1 on /dev/sda have been written, but we have been unable to inform the kernel of the change
19:39:05 <tflink> #info Proposed Blocker, NEW
19:39:29 <j_dulaney> +1 blocker
19:40:02 <cmurf> I just did this and the problem did not occur for me with TC4.
19:40:12 <j_dulaney> In fact, I just hit this in a VM
19:40:15 <cmurf> But +1
19:40:21 <nirik> +1
19:40:25 <nirik> (blocker)
19:40:28 <cmurf> See I did this in a VM and on a Macbook Pro - neither had this problem.
19:41:09 <tflink> "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...) with the default file system" ?
19:41:15 <cmurf> oh. duh. i have not externals.
19:41:26 <j_dulaney> tflink:  Indeed
19:41:27 <tflink> or am I bending intention too much with that criterion
19:41:30 <nirik> so it's a usb key thing, possibly only some
19:41:50 <cmurf> tflink: nope, taken literally, this bug meets that criterion
19:42:01 <cmurf> stretching nor bending required
19:42:25 <tflink> well, I'm pretty sure that I would be -1 blocker on this for alpha
19:42:40 <j_dulaney> But, this is final
19:42:48 * j_dulaney stands at +1 blocker
19:42:50 <nirik> I'm not sure spins kickstarts is where to fix this.
19:43:01 <nirik> should be whatever gnome component asks you if you want to mount something.
19:43:26 <akshayvyas> +1 blocker
19:43:46 <tflink> so do we punt or take as a blocker
19:43:55 <cmurf> might be livecd-tools since that's the component for producing desktop, but yeah it seems like it may be a gnome specific behavior
19:43:55 <tflink> it doesn't sound as if anyone is -1
19:44:40 <brunowolff> +1 blocker
19:45:28 <tflink> proposed #agreed - 820750 - AcceptedBlocker - Violates the F17 alpha release criterion "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...) with the default file system "
19:45:34 <j_dulaney> ack
19:45:34 <akshayvyas> ack
19:45:38 <cmurf> ack
19:45:38 <aspratyush> ack
19:45:40 <tflink> unless there is a suggestion for another criterion
19:45:51 <brunowolff> If there is special behavior needed for live images it might need something in spin-kickstarts, but probably the desktop/gnome guys would need to help figure out what.
19:45:58 <brunowolff> ack
19:46:18 <tflink> proposed #agreed - 820750 - AcceptedBlocker - Violates the F17 alpha release criterion "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...) with the default file system " but it's unclear whether spin-kickstarts is the right place to fix this
19:46:47 <j_dulaney> ack
19:46:52 * tflink assumes that old acks are still there
19:46:59 <tflink> #agreed - 820750 - AcceptedBlocker - Violates the F17 alpha release criterion "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...) with the default file system " but it's unclear whether spin-kickstarts is the right place to fix this
19:47:15 <tflink> ok, 2 more proposed blockers
19:47:30 * tflink proposes going through the proposed blockers and schedule another review meeting for monday
19:47:35 <tflink> #topic (815413) Preupgrade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causing systemd-loginctl not to know about user sessions, breaking PulseAudio
19:47:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815413
19:47:39 <buggbot> Bug 815413: unspecified, unspecified, ---, systemd-maint, MODIFIED, Preupgrade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causing systemd-loginctl not to know about user sessions, breaking PulseAudio
19:47:40 <tflink> #info Proposed Blocker, MODIFIED
19:48:23 <tflink> -1 blocker
19:49:14 <akshayvyas> this is kinda multiple damages :)
19:49:25 <j_dulaney> -1 blocker
19:49:44 <tflink> if it affected all or most upgrades, I'd be +1
19:49:55 <tflink> but as it sounds, this only affects a small percentage of upgrades
19:50:17 <michich> and it's easily fixed by re-running authconfig, which we can document
19:50:52 <cmurf> -1
19:50:55 <tflink> all the more reason to be -1 on it
19:50:55 <nirik> -1 blocker, releasenotes/document
19:51:00 <cmurf> yep
19:51:24 <akshayvyas> -1 blocker
19:51:43 <jsmith> -1 blocker, +1 documentation
19:52:05 <tflink> proposed #agreed - 815413 - RejectedBlocker - Given our current understanding; this will affect few upgrades and if it does, the fix is not difficult. The fix needs to be documented but this bug no longer seems like a blocker
19:52:35 <jsmith> ACK
19:52:37 <akshayvyas> ack
19:52:39 <cmurf> ack
19:52:42 <brunowolff> -1 blocker, document in common bugs and/or release notes
19:52:42 <aspratyush> ack
19:52:48 * tflink looks around for someone to #action on the docs
19:52:48 <brunowolff> ack
19:52:58 <tflink> #agreed - 815413 - RejectedBlocker - Given our current understanding; this will affect few upgrades and if it does, the fix is not difficult. The fix needs to be documented but this bug no longer seems like a blocker
19:53:15 <tflink> #info the fix for this (re-running authconfig) needs to be documented prior to release
19:53:30 <tflink> #topic (820973) Help -> Content function is broken
19:53:30 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820973
19:53:30 <tflink> #info Proposed Blocker, NEW
19:53:31 <buggbot> Bug 820973: unspecified, unspecified, ---, metherid, NEW, Help -> Content function is broken
19:53:53 <tflink> another clear blocker
19:53:55 <j_dulaney> +1 blocker as above
19:54:05 <aspratyush> another easy one :)
19:54:06 <aspratyush> +1
19:54:28 <akshayvyas> +1 bloocker
19:54:28 <cmurf> +1
19:54:37 <tflink> proposed #agreed - 820973 - AcceptedBlocker - Violates the F17 final release criterion "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:54:42 <cmurf> ack
19:54:42 <nirik> +1, ack
19:54:43 <akshayvyas> ack
19:54:46 <aspratyush> ack
19:54:53 <tflink> #agreed - 820973 - AcceptedBlocker - Violates the F17 final release criterion "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:55:13 <tflink> OK, that's it for the proposed blockers unless any new ones were proposed since we started
19:55:16 * tflink checks
19:56:03 <brunowolff> I need to go do yard work. So I am at my blockerness limit for today.
19:56:07 <cmurf> I'm considering proposing a blocker on 816228
19:56:11 <tflink> sigh, _someone_ added a blocker and then left the meeting
19:56:21 <cmurf> notme
19:56:55 <j_dulaney> ack
19:56:56 <tflink> well, it's a pretty clear blocker to me
19:57:09 <tflink> brunowolff: yeah, I need to get going too
19:57:16 <tflink> my brother is graduating this weekend
19:57:17 <j_dulaney> Oops
19:57:47 <akshayvyas> tflibk :cool
19:58:07 <tflink> honestly, let's just get this last one done even though martin wasn't nice enough to stick around and vote on it
19:58:13 <tflink> or any of these
19:58:17 <cmurf> what's the bug?
19:59:18 <akshayvyas> ??
19:59:32 <tflink> #topic (821077) Firstboot window does not fit the screen after install from F17 TC4 Final KDE Live
19:59:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=821077
19:59:36 <buggbot> Bug 821077: unspecified, unspecified, ---, mgracik, NEW, Firstboot window does not fit the screen after install from F17 TC4 Final KDE Live
19:59:37 <tflink> #link Proposed Blocker, NEW
19:59:51 <tflink> I think this is a pretty clear blocker
20:00:28 <tflink> violates the F17 alpha criterion "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted part
20:00:36 <cmurf> +1
20:00:51 <j_dulaney> +1 blocker
20:00:51 <akshayvyas> +1
20:00:53 <nirik> yeah, +1
20:00:55 <jsmith> +1 blocker
20:01:22 <tflink> proposed #agreed - 821077 - AcceptedBlocker - Violates the F17 alpha release criterion "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode
20:01:28 <akshayvyas> ack
20:01:29 <tflink> ack/nak/patch
20:01:34 <akshayvyas> ack
20:01:45 <jsmith> ACK
20:01:50 <aspratyush> ack
20:02:01 <tflink> #agreed - 821077 - AcceptedBlocker - Violates the F17 alpha release criterion "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This in
20:02:15 <cmurf> ack
20:02:22 <tflink> unless I'm missing something, it sounds like the consensus is to be done for the day (that's all of the proposed blockers)
20:02:23 <j_dulaney> ack
20:02:31 <j_dulaney> ack
20:02:39 <tflink> and I'll schedule another review meeting for monday or tuesday?
20:02:46 * nirik nods
20:02:53 <cmurf> yep
20:02:57 <j_dulaney> Monday would be better
20:03:09 <j_dulaney> Maybe right after the QA meeting?
20:03:14 <tflink> j_dulaney: yeah, I'm just not sure how timing with go/no-go etc. will work
20:03:25 <tflink> either way, it's time for ....
20:03:30 <tflink> #topic Open Floor
20:03:41 <tflink> any other issues/topics that people would like to see brought up?
20:03:43 <j_dulaney> Well, we want an RC before Go/No Go
20:03:46 <cmurf> 816228, question is
20:04:33 <cmurf> is this blocking on the basis that if not fixed, it would result in regression on Apple hardware from F16 (F17 not bootable). Criterion alpha 16 or beta 21.
20:04:38 <satellit_> write up documents for l-i-t-d to include --format --reset--mbr?
20:04:40 <tflink> cmurf: you sure you have the right bug number there?
20:04:59 <cmurf> rats
20:05:21 <cmurf> 816288
20:05:48 <j_dulaney> cmurf:  Apple hardware doesn't block
20:06:08 <tflink> j_dulaney: that's changing some
20:06:20 <tflink> but I'm not going to be +1 blocker right now
20:06:23 <tflink> I want to see more testing
20:06:38 <tflink> we already had fun with mactel stuff causing unintended problems with beta
20:06:56 <tflink> because the "fixes" caused unintentional breakage
20:07:15 <j_dulaney> Indeed
20:07:20 <cmurf> well this is with mactel-boot scripts post-install that affect the HFS+ /boot/efi partition
20:07:24 <tflink> oy, this is gonna require a new anaconda
20:07:39 <cmurf> tflink: that's the dilemma
20:07:47 <cmurf> but the thing is, the bug says this was fixed in 17.24
20:07:54 <cmurf> but 17.26 is in TC4 and it's not fixed.
20:08:09 <tflink> cmurf: I'm not against this as a blocker or NTH but would like to see more info
20:08:15 <cmurf> what more info
20:08:32 <tflink> what the fix is, why the current fix didn't work and testing
20:08:43 <cmurf> That'll have to come from mjg
20:08:48 <tflink> what the potential impact could be etc.
20:09:16 <cmurf> But presently, an EFI install of Live Desktop does not boot.
20:09:28 <tflink> oh, EFI and mactel-EFI?
20:09:33 <cmurf> And an EFI install from DVD is temporarily bootable, and once not bootable, cannot be booted.
20:09:34 <tflink> that would be a blocker
20:09:40 <cmurf> correct
20:10:00 * satellit_ add --efi to l-i-t-d commands and it does boot
20:10:22 <cmurf> Negative. This is about the installed system. Not the bootability of the installer medium.
20:10:31 <tflink> cmurf: are you asking whether it should be proposed as a blocker or are you asking to have it considered now?
20:11:19 <cmurf> Q1: should i write it up as blocker, if so on what basis. Q2: This bug says LiveCD, but (nearly) the same result occurs with DVD installs, so should that be a separate bug write up?
20:12:10 <tflink> cmurf: yeah, propose it as a blocker but clarify that it isn't just mactel
20:12:28 <tflink> file a different bug for the non-live case - we can always dupe them if they turn out to be the same thing
20:12:29 <cmurf> It is only EFI mactel as far as I know.
20:12:58 <cmurf> my earlier "correct" was ill timed
20:13:04 <tflink> propose it as a blocker anyways but I'm less +1 on it if it's just macs this close to release
20:13:30 <tflink> then again, the decision is not 100% up to me :)
20:13:44 <cmurf> ok that's all i have
20:13:51 <tflink> cool, anything else?
20:14:10 * tflink sets the fuse for [0,5] minutes
20:14:22 * tflink will send out meeting minutes shortly
20:14:37 * tflink will also secretarialize later tonight/tomorrow if nobody else does it
20:15:06 <tflink> the next blocker review meeting will be early next week (likely monday) to finish going over the accepted blockers and proposed NTH bugs
20:15:40 * tflink doesn't feel like waiting the whole 5 minutes - starts blowing on the fuse
20:15:49 * j_dulaney cuts the fuse
20:16:01 <tflink> 5 ... 4 ... 3 ... 2 ... 1 ... done
20:16:12 <tflink> thanks for coming everyone!
20:16:15 <tflink> #endmeeting