17:01:41 <tflink> #startmeeting f18final-blocker-review-1.1
17:01:41 <zodbot> Meeting started Thu Nov 29 17:01:41 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:41 <tflink> #meetingname f18final-blocker-review-1.1
17:01:42 <tflink> #topic Roll Call
17:01:42 <zodbot> The meeting name has been set to 'f18final-blocker-review-1.1'
17:02:06 * pschindl is here
17:02:15 * satellit listening
17:02:17 <tflink> hopefully we'll have enough people today
17:02:36 * kparal +1 blocker
17:02:50 <kparal> what, too early?
17:02:55 * tflink will be back in a minute
17:06:20 <kparal> where is adamw? we haven't been fired for quite a long time
17:06:58 <tflink> kparal: don't tempt him
17:07:40 <kparal> the tiger seems to be asleep
17:08:52 * tflink waits another couple of minutes for others to show up
17:09:05 <tflink> kparal: can you secretarialize if adamw doesn't show up in time?
17:09:36 <kparal> tflink: yes
17:09:39 <tflink> thanks
17:10:03 <kparal> adamw: I know this is what you have been waiting for, now you can come up
17:10:46 <akshayvyas> or you will b ddos'ed by all :D
17:10:46 <kparal> I see netsplits
17:10:47 <cpu> satellit: unfortunately I still get the same error when I try to mount the iso on the cd drive.  iso seems ok, since I can mount it otherwise with no problem. any suggestions?
17:11:21 <tflink> I think we have enough people to get started
17:11:42 <tflink> Time for some exciting boilerplate!
17:11:47 <tflink> #topic Introduction
17:11:59 <tflink> #chair adamw kparal
17:11:59 <zodbot> Current chairs: adamw kparal tflink
17:12:03 <tflink> Why are we here?
17:12:04 <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:12:10 <tflink> #info We'll be following the process outlined at:
17:12:10 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:12:17 <tflink> #info The bugs up for review today are available at:
17:12:17 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:12:24 <tflink> #info The criteria for release blocking bugs can be found at:
17:12:25 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:12:25 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:12:25 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:12:34 <tflink> #info Up for review today are:
17:12:42 <tflink> #info 52 Proposed Blockers
17:12:42 <tflink> #info 3 Accepted Blockers
17:12:42 <tflink> #info 23 Proposed NTH
17:12:42 <tflink> #info 1 Accepted NTH
17:12:55 <tflink> thoughts on when to cap the meeting?
17:13:03 <tflink> 3 hours is what we did for beta
17:13:18 <kparal> that's the maximum I'm able to survive
17:13:54 <tflink> I don't think that we'd survive if we tried to do everything today
17:14:26 <kparal> 3h cap
17:14:28 <akshayvyas> tflink: decide the tim after 1 hr
17:14:29 <tflink> since there are no other suggestions than 3 hours
17:14:52 <tflink> #info The meeting will be capped at 3 hours. If we are not done by then, another meeting will be scheduled.
17:15:06 <adamw> sorry, overslept
17:15:40 <tflink> .fire adamw
17:15:40 <zodbot> adamw fires adamw
17:15:52 <adamw> but..but..
17:15:57 * kparal handing his secretary job to adamw as a punishment
17:15:59 <tflink> OK, let's get started with the proposed blockers
17:16:57 * tflink notes that he lost the list from yesterday in a botched upgrade but he thinks that he filtered out the little progress from yesterday
17:17:04 <tflink> #topic (876716) anaconda crashes after setting root password
17:17:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876716
17:17:04 <tflink> #info Proposed Blocker, anaconda, NEW
17:17:16 <kparal> that has been punted yesterday, no?
17:17:31 <adamw> yes, but we got quite a bit of info
17:17:33 <kparal> some people responded on the list they saw it too
17:17:38 <kparal> but it's damn hard to reproduce
17:17:43 <adamw> i think like 2-3 people on the list said they'd seen it, which tilts me towards +1
17:17:49 <tflink> yeah, that's why I brought it up again
17:18:10 <kparal> can we make it a blocker when we can't reproduce it?
17:18:20 <kparal> it's nasty, I know, but... how to fix it?
17:18:30 <akshayvyas> i am -1 here
17:18:34 <kparal> if we know how to trigger it, I'd vote +1 blocker
17:18:44 <tflink> punt again, then?
17:18:44 <kparal> currently I'm not so sure
17:19:01 <kparal> I think +1 nth for sure, and +1 blocker if we find a reproducer
17:19:29 <kparal> the problem is that it is a C module, so it crashes the whole anaconda and you can't do much about it
17:19:39 <kparal> that's the way C modules in Python work. they must not crash
17:20:03 <akshayvyas> i installed three times and i never hit this plus a recent mail in test list says anaconda is in good shape
17:21:01 <kparal> akshayvyas: that doesn't mean it's not a serious bug
17:21:55 <akshayvyas> kparal:well i cant say anything about it but really i installed beta 3 times
17:22:01 <tflink> proposed #agreed 876716 - It seems as if more people are hitting this than show up on the bug but we still don't have a reliable reproducing case or debug info - will wait on decision in case either one of those things is found and revisit later.
17:22:19 <kparal> akshayvyas: I installed 300 times and saw it 2 times
17:22:32 <kparal> ack
17:22:35 <adamw> ack
17:22:40 <pschindl> ack
17:22:41 <akshayvyas> kparal: :)
17:22:42 <akshayvyas> ack
17:23:27 <tflink> #agreed 876716 - It seems as if more people are hitting this than show up on the bug but we still don't have a reliable reproducing case or debug info - will wait on decision in case either one of those things is found and revisit later.
17:23:36 <tflink> #topic (869424) RuntimeError: Error running systemctl: No such file or directory
17:23:39 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869424
17:23:41 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:23:43 <tflink> bah, too many things to do at the same time
17:23:55 * tflink runs 'git clone tflink' but it doesn't work
17:24:06 <tflink> #topic (869424) RuntimeError: Error running systemctl: No such file or directory
17:24:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869424
17:24:11 <tflink> damnation
17:24:13 <tflink> #undo
17:24:13 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x28d9f1d0>
17:24:14 <tflink> #undo
17:24:14 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1dd12bd0>
17:24:16 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:24:19 <tflink> #Undo
17:24:19 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x21842490>
17:26:03 * kparal is confused
17:26:26 <adamw> me too
17:26:53 <adamw> anyone else seen this?
17:27:07 <tflink> only 1 reproducer since it was reported fix and no tracebacks, no details
17:27:09 <adamw> and anyone know if karsten is actually seeing it or just doing bugzilla maintenance?
17:27:12 <adamw> i'm -1 as it stands
17:27:44 <tflink> I could be +1 if it's actually still happening as described
17:28:36 <tflink> but at the moment, I'd say reject or punt
17:28:45 <kparal> punt a re-test
17:28:47 <kparal> *and
17:29:05 <tflink> other thoughts?
17:30:03 <adamw> the reproducer was just "Selected Software Development", so shouldn't be hard to re-test.
17:30:14 * kparal trying now
17:30:49 <tflink> proposed #agreed 869424 - This needs to be re-tested with latest anaconda in order to determine whether or not the original bug has been fixed. Will re-visit after the re-testing is complete
17:31:30 <kparal> ack
17:31:32 <akshayvyas> ack
17:31:37 <kparal> seems like it was run with kickstart?
17:33:02 <tflink> I wonder if the blocker is just moving from ppc blocker to PA blocker with the report in c#26
17:33:09 <tflink> any other ack/nak/patch?
17:33:21 <kparal> tflink: what's PA?
17:33:25 <tflink> primary arch
17:33:47 <kparal> I'm halfway the installation, no crash
17:33:54 <tflink> i686 and x86_64 vs. ppc, arm etc.
17:34:11 <tflink> #agreed 869424 - This needs to be re-tested with latest anaconda in order to determine whether or not the original bug has been fixed. Will re-visit after the re-testing is complete
17:34:28 <tflink> #topic (880263) DMError: partition activation failed for 'mpatha'
17:34:28 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=880263
17:34:28 <tflink> #info Proposed Blocker, anaconda, NEW
17:34:38 <tflink> we seem to have lost pschindl and adamw
17:34:44 * adamw is around, just splitting time
17:34:53 <tflink> git clone adamw
17:35:44 <adamw> oh my god, it's hideous
17:36:01 <tflink> the clone or the bug?
17:36:19 <tflink> I'm not 100% sure what's going on here and what setups will hit this outside of mpath storage
17:37:05 <kparal> punt and ask #anaconda for feedback?
17:37:15 <pschindl> +1
17:37:17 * tflink still wants a utility to slap people who propose blockers w/o justification
17:37:20 <kparal> or maybe invite someone from #anaconda here now?
17:37:47 * tflink is looking for hamzy
17:38:09 * adamw reading
17:38:47 <adamw> the last comment sort of explains it a bit
17:39:10 <adamw> so this is about doing a multipath install to a device which contains a partition that's already handled by device-mapper?
17:39:30 <tflink> sounds like
17:39:40 <tflink> which doesn't sound very blockery to me
17:39:43 <tflink> not for PA, anyways
17:40:46 <adamw> well, i'm not 100% sure, it may have crashed earlier, so it may be an 'anaconda crashes when evaluating crazy disk layout' bug
17:40:52 <adamw> just poking through the logs to find out
17:41:50 <cpu> oops, my sha256sum is wrong-- that explains why vbox doesn't work
17:42:55 <tflink> dlehman: any insight on https://bugzilla.redhat.com/show_bug.cgi?id=880263 as a blocker? Is this going to be a big problem for non-ppc or is this a case of 'anaconda crashes when attempting to parse a crazy disk layout'?
17:43:26 <adamw> yeah, seems like it crashed early
17:43:58 <adamw> so this is evaluation, not creation
17:44:07 <dlehman> seems to me like whatever udev rules start lvm automatically need to be checking for mpath first
17:45:17 <dlehman> and also, they need to stop moving shit around because I am sick and tired of fixing this exact same problem at least once in every release
17:45:36 <dlehman> (lvm and/or md devices getting auto-started)
17:45:55 <adamw> dlehman: okay, but the question is more about how crazy your partition setup has to be to hit the bug, not how to fix it
17:46:14 <adamw> always when evaluating blocker status our primary question is 'how common is this bug going to be'
17:46:28 <tflink> I imagine it's a "if you don't have mpath, you can't hit this"
17:47:00 <dlehman> looks to me like "IFF you have lvm on mpath you will hit this"
17:47:25 <tflink> which I'm thinking -1 blocker on
17:47:30 <adamw> and LVM is the default. although if you're installing to multipath, chances are you don't care much about defaulst.
17:47:33 <adamw> defaults.
17:47:46 <tflink> since you need to install with ks for mpath
17:47:53 <adamw> you do now but you didn't before.
17:47:56 <adamw> it's in the UI for oldUI.
17:48:24 <adamw> it may be a use case we don't see much, but i think it's kind of important, that's why we support it after all...
17:48:39 <adamw> if this is 'any lvm-on-multipath setup will crash the installer during init' i think I'm +1.
17:49:22 <adamw> if there was some kind of workaround i'd be -1.
17:50:04 <tflink> other votes
17:50:11 <tflink> I'm convinced to do +1
17:50:20 <adamw> dlehman: wdyt?
17:50:24 <tflink> but I wish we had some mpath hw to test with
17:51:06 <dlehman> +1
17:52:01 <tflink> thoughts on criterion to use?
17:52:24 <tflink> I was thinking "The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method" for mpath
17:54:42 <adamw> sec
17:54:58 <adamw> i'd go with the alpha "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
17:55:06 <adamw> in the case of a multipath device being present, the installer doesn't run.
17:55:10 <tflink> I suppose this is scanning, not installing
17:55:12 <adamw> er, lvm-on-multi.
17:55:14 <adamw> yeah.
17:57:08 <tflink> proposed #agreed 880263 - AcceptedBlocker - Violates the following F18 alpha release criterion for systems using LVM on mpath: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media ..."
17:57:43 <adamw> ack
17:57:56 <pschindl> ack
17:57:57 <kparal> ack
17:58:07 <tflink> #agreed 880263 - AcceptedBlocker - Violates the following F18 alpha release criterion for systems using LVM on mpath: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media ..."
17:58:18 <tflink> #topic (876218) kernel boot + nfsiso repo = hang on reboot
17:58:18 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876218
17:58:18 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:58:23 <cpuobsessed> oh snap, didn't know there was meeting
17:59:00 <adamw> now you do!
17:59:16 <cpuobsessed> as long as i'm here...
17:59:35 * kparal always though there were just drawbacks doing in #fedora-qa. it seems that there are also advantages in that
18:00:32 <cpuobsessed> robatino is here, now it's a party!
18:00:59 <tflink> thoughts on blockery-ness?
18:01:17 <adamw> what, we have to do work at this party?
18:01:40 <adamw> oh, this one again.
18:01:47 <kparal> adamw: sorry
18:01:57 <adamw> so again, background: we had this same bug for f17 and rejected it as final blocker, though that was something of a fudge
18:02:10 <adamw> if we accept it this time we are saying we were wrong last time, but hey, we've been wrong before. :p
18:02:17 <kparal> I would say we rejected it because "we really need to release now" reason
18:03:00 <kparal> let's do better this time
18:03:22 <cpuobsessed> sounds like an edge case to me
18:03:36 <cpuobsessed> but should still be addressed
18:04:11 <kparal> the F17 experience shows that it wasn't addressed
18:04:16 <akshayvyas> i am +1 blocker
18:04:29 <adamw> kparal: well, i was slightly off there: i think it's not actually the same bug, a different bug with the same effect.
18:04:30 <adamw> though imbw.
18:04:40 <kparal> adamw: you're right, it's probably something a bit different
18:04:54 <kparal> the F17 bug had updates.img that was working OK
18:05:47 * kparal would like to consider the ability to reboot as part of the installation process
18:05:59 <tflink> isn't it?
18:06:27 <tflink> "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 ..."
18:07:25 <tflink> sounds like we have +2 blocker
18:07:37 <tflink> I'm probably somewhere between +.5 and +1
18:07:41 <tflink> any -1s?
18:07:52 * adamw is +/-0ish
18:08:04 <pschindl> +1
18:08:47 <tflink> proposed #agreed 876218 - Violates the following F18 release criterion for NFSISO and rebooting cleanly: "The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options"
18:09:07 <akshayvyas> ack
18:09:13 <pschindl> ack
18:09:25 <tflink> wait, that's not complete
18:09:34 <tflink> proposed #agreed 876218 - AcceptedBlocker - Violates the following F18 release criterion for NFSISO and rebooting cleanly: "The installer must be able to use the HTTP, FTP and either NFS or NFSISO remote package source options"
18:09:38 <tflink> that's better
18:09:57 <adamw> ack
18:10:10 <kparal> tflink: it if was, we wouldn't be hesitating whether this is a blocker
18:10:10 <kparal> it would violate "must be able to install" criteria
18:11:39 <adamw> i guess we coul explain it a bit more
18:11:42 <tflink> proposed #agreed 876218 - AcceptedBlocker - Violates the following F18 release criterion for NFSISO based installs: "In most cases, a system installed according to any of the above criteria 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."
18:11:51 <adamw> no, i know
18:12:13 <adamw> from Beta
18:12:14 <adamw> "Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention) "
18:12:27 <adamw> is violated in the case of a kickstarted NFSISO install.
18:12:30 * kparal lagged. 30 new comments appeared out of the blue
18:13:09 <kparal> adamw: that is a nice criterion
18:13:18 <tflink> adamw: but that criterion only covers kickstarts that come out of an install
18:13:18 <kparal> I didn't know we even have it
18:14:17 <kparal> doesn't have to cover just kickstarts. the reboot is part of the process
18:14:29 <kparal> and requires manual intervention in this case, until fixed
18:14:31 <tflink> yeah, I was confusing the two criteria
18:14:57 * kparal has a new favorite criterion
18:15:09 <tflink> I don't see how that's better in this case, though
18:15:24 <kparal> it's the same
18:15:31 <kparal> in this case
18:15:37 <kparal> acky acky
18:15:42 <tflink> other ack/nak/patch?
18:15:58 <adamw> tflink: your criterion reads 'on the first boot after installation'.
18:16:09 <adamw> tflink: which kind of takes it out of contention for covering a hang during reboot from the installer.
18:16:38 <tflink> huh?
18:16:49 <tflink> isn't this but about the first boot after installation?
18:16:54 <tflink> s/but/bug
18:17:06 <kparal> that's somewhat true. but let's not waste time on this, we all agree it's a blocker
18:17:32 <kparal> tflink: the hang occurs after the installation, before first system boot
18:17:51 <tflink> I am so lost here
18:18:08 <tflink> why isn't that covered by "must install with NFS and NFSISO"?
18:18:09 <adamw> tflink: no, it's about it hanging when you reboot at the end of install, not hanging on the first boot after install.
18:18:23 <adamw> tflink: because the system installed fine. it just failed to reboot at the end of install.
18:18:27 <kparal> you install -> anaconda finished -> hang
18:18:47 <kparal> that's why I say reboot should be considered part of installation
18:19:08 <tflink> proposed #agreed 876218 - AcceptedBlocker - Violates the following F18 release criterion for NFSISO based installs: "Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention)"
18:19:33 <kparal> ack
18:19:36 <tflink> proposed #agreed 876218 - AcceptedBlocker - Violates the following F18 release criterion for reboots during/after NFSISO based installs: "Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention)"
18:20:16 <adamw> ack
18:20:26 <tflink> more ack/nak/patch?
18:20:30 <pschindl> ack
18:20:33 <akshayvyas> ack
18:20:37 <tflink> good lord, 4 bugs in 1.5 hours?
18:20:43 <tflink> #agreed 876218 - AcceptedBlocker - Violates the following F18 release criterion for reboots during/after NFSISO based installs: "Any installation method or process designed to run unattended must do so (there should be no prompts requiring user intervention)"
18:20:49 <tflink> #topic (875599) anaconda keeping error status after Change the installation source to point to a custom HTTP/FTP repository
18:20:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875599
18:20:54 <pschindl> and only 49 left :)
18:20:55 <tflink> #info Proposed Blocker, anaconda, NEW
18:21:04 <pschindl> thats about another 18 hours
18:21:38 <tflink> at least it's less than 24, I suppose :-/
18:23:05 <tflink> I'm leaning towards -1 on this, assuming I'm understanding it
18:23:33 <kparal> if you change the repo, it's hard to confirm default package selection
18:23:40 <pschindl> I think it's more nth than blocker
18:23:41 <tflink> the bug is that if your installation source is bad when doing package selection, you have to make some change in the package set selection spoke before the errors are refreshed?
18:23:41 <kparal> you have to select KDE and then back GNOME
18:23:53 <adamw> that's intentional.
18:23:57 <kparal> tflink: the installation source is correct
18:24:00 <adamw> i filed a bug on it or queried #anaconda before, it is not a bug.
18:24:14 <kparal> this bug report speaks about correct repo URLs
18:24:23 <adamw> the idea is that when you change installation source the package set stuff could theoretically change too, so you should be forced through that spoke.
18:24:44 <tflink> ok, so the package set errors out for some unknown reason and things have to be manually refreshed in order to continue install?
18:24:45 <kparal> yes, the only problem is that GNOME can't be easily confirmed
18:24:50 <adamw> i'm not convinced i agree, and it should at least allow you to just pop in, leave GNOME selected, and leave again
18:24:54 <adamw> but i'm not sure that's a blocker.
18:25:29 <tflink> I think the bug here isn't so much that you have to change it, but that there was an initial error that doesn't have an intuitive recovery
18:25:32 <kparal> probably not, that's why I proposed it for NTH discussion as well
18:25:45 <tflink> how often does this happen?
18:25:54 <kparal> tflink: always
18:25:54 <kparal> let me rephrase
18:26:30 <akshayvyas> i am +1 nth
18:26:32 <kparal> 1. you boot 2. you change repo to a _correct_ repo 3. GNOME has orange icon 4. you open the package selection dialog and close it 5. GNOME still has an orange icon
18:26:53 <kparal> workaround: 6. open package selection, choose KDE, confirm 7. open package selection, choose GNOME, confirm
18:27:00 <kparal> is that clearer now?
18:28:03 <adamw> -1 blocker. nth i don't care about at this point.
18:28:14 <kparal> it's a minor bug, really. but if you change repo (like from internal DVD repository to Closest mirror), some people might now understand how to select GNOME
18:28:38 <kparal> unless they change the selection forth and back, it displays an error
18:29:08 <kparal> *might not
18:29:19 <kparal> (instead of might now)
18:30:10 <kparal> I'm +0 blocker /+1 nth
18:30:28 <pschindl> +1 nth
18:31:21 <tflink> proposed #agreed 875599 - RejectedBlocker, AcceptedNTH - While this is a problem with a rather non-intuitive solution, it doesn't clearly violate any of the F18 release criteria. A well-tested fix would be considered after freeze.
18:31:30 <akshayvyas> ack
18:31:54 <pschindl> ack
18:32:00 <kparal> ack
18:32:08 <tflink> #agreed 875599 - RejectedBlocker, AcceptedNTH - While this is a problem with a rather non-intuitive solution, it doesn't clearly violate any of the F18 release criteria. A well-tested fix would be considered after freeze.
18:32:24 <tflink> #topic (858628) Some buttons and labels in Anaconda can't be localized
18:32:24 <adamw> ack
18:32:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=858628
18:32:25 <tflink> #info Proposed Blocker, anaconda, NEW
18:33:58 <kparal> this is +1 blocker from me, the UI shouldn't have hardcoded strings
18:34:35 <tflink> I don't think that we have a criterion for installer translation, though
18:34:41 <tflink> we probably should
18:34:52 <adamw> the criterion cited in the bug is fine.
18:34:55 <adamw> installation is a critpath action.
18:35:15 <tflink> but its not in a DE
18:35:53 <tflink> proposed #agreed 858628 - AcceptedBlocker - Prevents translation of some strings in the installer and thus violates the following F18 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
18:36:06 <pschindl> ack
18:36:40 <adamw> close enough, ack
18:36:48 <akshayvyas> ack
18:36:56 <kparal> ack
18:37:01 <tflink> #agreed 858628 - AcceptedBlocker - Prevents translation of some strings in the installer and thus violates the following F18 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
18:37:14 <tflink> #topic (875477) ValueError: name already in use
18:37:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875477
18:37:14 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
18:38:15 <kparal> this seems like a generic bug that is not really tied to btrfs partition mentioned in the report
18:38:23 <kparal> according to comment 20
18:39:42 <kparal> I guess Reartes might have two or more disks
18:39:57 <kparal> with more VGs
18:40:09 <kparal> and if some LV names clashes, anaconda explodes
18:40:14 <kparal> but that's just my wild guess
18:41:34 <tflink> yeah, it sounds like anaconda is just checking the lv names instead of using vg+lv name
18:41:37 <adamw> see comment #17. seems like a fairly simple reproducer.
18:41:48 <adamw> i'm +1 on the basis of that and dlehman's comment.
18:42:19 <adamw> basically looks like you're going to hit this if you're LVM installing over an existing LVM install and the LV will use the same name as before, aiui.
18:42:20 <dlehman> a patch has been reviewed and is going to pushed today
18:42:24 <drindt> hello there, i tried out the beta desktop today, and experienced that my Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24) can't connect to a wi-fi router, is there a known workaround?
18:42:26 <adamw> which isn't terribly uncommon, i don't think.
18:42:36 <tflink> so "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."?
18:42:45 <kparal> tflink: will do
18:43:10 <tflink> any other votes, I'm +1
18:43:18 <pschindl> +1 blocker
18:43:18 <kparal> +1
18:43:24 <dlehman> adamw: actually, we handle that fine. the bug hits if you have a md or btrfs 'root' and then make an lvm fedora-root
18:43:24 <akshayvyas> +1 here
18:43:52 <tflink> proposed #agreed 875477 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."
18:44:19 <pschindl> ack
18:44:23 <kparal> ack
18:44:24 <akshayvyas> ack
18:44:30 <tflink> #agreed 875477 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."
18:44:48 <tflink> #topic (876547) ValueError: ('invalid size specification', '-472.028417969 mb')
18:44:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876547
18:44:54 <tflink> #info Proposed Blocker, anaconda, NEW
18:45:20 <kparal> I see variations of this bug all the time
18:45:49 <kparal> seems I'm the only one :)
18:46:13 <adamw> oh another of these...yay.
18:46:19 <adamw> dlehman: i thought you'd stomped most of these?
18:46:43 <zodbot> Ticket notification - f18finalnicetohave: [Bug 875599] anaconda keeping error status after Change the installation source to point to a custom HTTP/FTP repository <https://bugzilla.redhat.com/show_bug.cgi?id=875599>
18:48:52 <dlehman> kparal: at some point when you hit that bug, click on debug an find me in irc to gather some info
18:49:29 <dlehman> adamw: yeah, most of them are indeed fixed. this one where it's way way off, I never got to the bottom of.
18:49:48 <wwoods> so, someone was asking me about a fedup "design document"
18:49:50 <adamw> oh, right.
18:50:01 <tflink> wwoods: I did at some point
18:50:12 <tflink> someone else was asking, too but I forget who
18:50:14 <wwoods> tflink: so what did you want to know, and for what reason?
18:50:18 <adamw> i'm +1 punt, leaning -1 blocker since we don't seem to have any other cases of this.
18:50:48 <wwoods> the outline in http://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ has the overall design
18:50:48 <tflink> it'd be nice to know if it was arch specific, too
18:51:17 <tflink> kparal: are you always using i686 when you've been hitting this?
18:51:40 <kparal> tflink: the original description is 64bit
18:51:50 <adamw> this and https://bugzilla.redhat.com/show_bug.cgi?id=863670 are the only remaining open 'invalid size specification' bugs.
18:52:05 <dlehman> it's almost certainly triggered by the contents of your disk(s)
18:52:27 <wwoods> I have lots of my own design notes etc. around but those aren't going to be more helpful than either that outline, the READMEs in the packages, or the code itself
18:52:39 <tflink> wwoods: I'm trying to do too many things ATM so I might be forgetting something but I'm mostly interested in any plans for updates of the upgrade.img post-release, whether --instrepo is going to be required for final and any projected timelines for the GUI etc.
18:52:43 <kparal> let's punt
18:53:15 <kparal> we will wait whether someone else also hits that
18:53:21 <wwoods> 1) I'd like to have some kind of updates.img support but I haven't written anything yet; I don't consider that as important as some of the other existing problems
18:53:31 <tflink> wwoods: the grub upgrade issue is going to be interesting as well but I think we've covered that outside the design docs
18:53:36 <adamw> wwoods: sorry to shut you down when you're being helpful, but can you hold it till after the blocker meeting?
18:53:48 <adamw> or do this in #anaconda
18:53:53 <adamw> or else the meeting will get messy
18:53:56 <adamw> thanks
18:53:56 <wwoods> didn't know you were in the middle of a meeting. sorry.
18:54:09 <wwoods> (don't we have a channel for that?)
18:54:13 * kparal proposes doing all meetings in #fedora-qa-meeting
18:54:28 <tflink> it's hard to get a 3 hour chunk in #fedora-meeting
18:54:36 <kparal> tflink: ^^
18:54:53 <kparal> we have plenty of available room names I think
18:54:54 <tflink> why not just move it back to bugzappers, then?
18:55:03 <kparal> doesn't matter
18:55:15 <tflink> we moved to #fedora-qa because people were thought to be more likely to be here
18:55:34 <kparal> hmm, that's a good point
18:55:44 <kparal> let's discuss this on the test list
18:56:03 <tflink> proposed #agreed 876547 - At this point, there aren't enough debug logs or reproducers to make a call on blocker status, will revisit when there is more available information and more tests done.
18:56:11 <kparal> ack
18:57:07 <tflink> other ack/nak/patch?
18:57:13 * kparal pokes pschindl to say 'ack'
18:57:14 <adamw> ack
18:58:09 * adamw puts on pschindl mask
18:58:10 <adamw> ack
18:58:24 <pschindl> ack :)
18:58:25 <tflink> #agreed 876547 - At this point, there aren't enough debug logs or reproducers to make a call on blocker status, will revisit when there is more available information and more tests done.
18:58:37 <tflink> #topic (873293) custom storage ui fails to create lvm unless all disks have free space
18:58:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873293
18:58:42 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
18:59:45 <kparal> would be nice to know whether this is workaround-able or not
19:00:23 <kparal> and the title seems to be a bit misleading
19:00:49 <adamw> the workaround would be to create the / partition as the right size in the first damn place.
19:00:52 <adamw> or create /boot before you create /.
19:01:15 <kparal> I don't see why should I do that
19:01:27 <adamw> because it's the workaround?
19:01:36 <kparal> yeah well, ok
19:01:42 <adamw> i mean, you asked if it's workaroundable, clearly it is. :)
19:01:48 <tflink> this feels like self-induced pain
19:02:13 <adamw> tflink: i'm kinda borderline; obviously it's asking the installer to do a lot of legwork for you, but otoh, it kind of sucks when it crashes and you're just Doin' Stuff.
19:02:14 <kparal> the described reproducer is a quite a standard procedure
19:02:15 <tflink> or am I missing something?
19:02:27 <tflink> it sounds like he's trying to create a partition larger than any single disk in the system
19:02:30 <tflink> without using LVM
19:02:40 <tflink> or RAID
19:02:57 <kparal> tflink: well anaconda fixes that just fine, it just crashes afterwards
19:03:51 <tflink> I'm thinking more -1 blocker, +1 nth
19:04:07 <tflink> don't attempt to create standard partitions larger than your source disks
19:04:32 <kparal> but he hadn't, it was LVM. only afterwards he changed it to standard part
19:04:47 <kparal> what happened to " Rejecting obviously invalid operations without crashing "?
19:05:17 <adamw> man, people really seem to love those criteria that suck. but that is a point.
19:05:20 <adamw> the crash sucks.
19:05:26 <tflink> I'm not arguing that
19:05:28 <pschindl> it doesn't crash, does it?
19:05:39 <kparal> does it crash during the installation, or before that?
19:05:42 <adamw> there's a tb attached.
19:05:44 <tflink> just wondering at which point we cut off the "don't do stupid stuff" bugs
19:05:52 <kparal> if some partitions are already created/formatted, that's very bad
19:05:59 <dlehman> patch for this one's ready to be pushed as well
19:06:21 <kparal> dlehman: does it crash after "Begin installation" or before?
19:06:39 <adamw> i'm small +1 blocker. if a patch is ready let's just go with a majority vote and move on.
19:06:45 <adamw> kparal: does it really matter where it crashes?
19:06:47 <adamw> oh, i see.
19:06:49 * dlehman checks if it crashses
19:06:58 <kparal> adamw: yes, because it might format your disk in the mean time
19:07:01 <adamw> the anaconda.log stops at the error.
19:07:04 <kparal> before it crashes
19:07:28 <dlehman> it doesn't crash
19:07:36 <dlehman> adamw, kparal: note there is no crash.
19:07:48 <kparal> ? I see anaconda-tb with a traceback
19:07:53 <dlehman> and yes -- it makes some difference whether you crash before changing disk contents or after/during
19:08:23 <adamw> dlehman: so what happens exactly?
19:08:23 <kparal> how come that anaconda-tb is created when it doesn't crash?
19:08:31 <dlehman> yes, and if you look at that traceback you'll see it was generated using killall -HUP anaconda
19:08:40 <kparal> ah
19:08:50 <dlehman> adamw: you get a message saying we failed to create the device, you're back where you started.
19:09:12 <adamw> this all happens during the custom part screen?
19:09:12 <kparal> in that case it doesn't sound that bad
19:09:14 <dlehman> it's something we should and will be able to do for final, but there's no crash
19:09:17 <dlehman> right
19:09:17 <adamw> and you get to try again?
19:09:21 <adamw> okay, then -1.
19:09:29 <kparal> I'm -1 as well in that case
19:09:29 <adamw> -1 blocker, +1 nth.
19:09:30 <pschindl> +1 nth
19:09:37 <dlehman> right, but it'll fail again unless you remove the full disk from the disk set
19:09:47 <kparal> dlehman: how can I know that the traceback was triggered by killall -HUP?
19:09:49 <dlehman> again, patch is going to be pushed today
19:10:11 <dlehman> kparal: main hint is there's no error or exception
19:10:31 <kparal> I see
19:10:58 <tflink> so this isn't a crash and the user can fix the layout after an oviously invalid operation?
19:11:03 <dlehman> right
19:11:16 <kparal> -1/+1
19:11:19 <tflink> -1/-1
19:11:26 <dlehman> you'd have to be fairly savvy to identify the cause of the problem and get past it, though
19:11:58 <dlehman> (click on configure/tools/gears icon, note full disk in specified disk set)
19:12:14 <adamw> moving on!
19:12:28 <tflink> proposed #agreed 873293 - RejectedBlocker, AceptedNTH - This isn't a crash but it would be nice if the installer had a clearer error message to identify the cause of this issue, it is recoverable. Rejected as a blocker for F18 final but a tested fix would be considered past freeze.
19:12:52 <pschindl> ack
19:12:57 <akshayvyas> ack
19:13:38 <kparal> ack
19:14:05 <tflink> #agreed 873293 - RejectedBlocker, AceptedNTH - This isn't a crash but it would be nice if the installer had a clearer error message to identify the cause of this issue, it is recoverable. Rejected as a blocker for F18 final but a tested fix would be considered past freeze.
19:14:29 <tflink> #topic (876789) FormatDestroyError: error wiping old signatures from /dev/md/Volume0_0p2: 1
19:14:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876789
19:14:34 <tflink> #info Proposed Blocker, anaconda, NEW
19:16:23 <kparal> +1 blocker
19:16:25 <dlehman> kparal: I figured out your invalid size bug. I have a patch.
19:16:33 <kparal> dlehman: great
19:17:05 <adamw> +1 for sure
19:17:15 <adamw> if i'd known more i might even have wanted to block beta for this, but eh
19:17:29 <akshayvyas> +1 blocker
19:18:00 <tflink> proposed #agreed 876789 - AcceptedBlocker - Violates the following F18 beta release criterion for existing LVM LVs: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."
19:18:12 <kparal> ack
19:18:19 <akshayvyas> ack
19:18:30 * tflink is still trying to do too many things at the same time but I think that's right
19:19:23 <adamw> ack
19:19:24 <tflink> other ack/nak/patch?
19:19:30 <tflink> #agreed 876789 - AcceptedBlocker - Violates the following F18 beta release criterion for existing LVM LVs: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."
19:19:34 <adamw> er well...oh well
19:19:43 <adamw> you can actually hit it with things other than LVs, but close enough.
19:19:46 <tflink> #topic (879612) OSError: [Errno 2] No such file or directory: '/mnt/install/isodir/dvd.iso'
19:19:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=879612
19:19:51 <tflink> #info Proposed Blocker, anaconda, NEW
19:19:56 <adamw> oh, wait, no, has to be an lv. ignore me.
19:20:31 <zodbot> Ticket notification - f18finalnicetohave: [Bug 873293] custom storage ui fails to create lvm unless all disks have free space <https://bugzilla.redhat.com/show_bug.cgi?id=873293>
19:20:58 <kparal> this is a problem when selection iso file from an existing partition
19:21:04 <kparal> which is a supported installation method
19:21:39 <kparal> *selecting
19:22:18 <pschindl> +1 blocker
19:23:18 <kparal> yes, seems to be violating the criteria quite right
19:23:31 <akshayvyas> +1 bocker
19:23:49 <akshayvyas> +1 bocker
19:24:17 <tflink> any other votes?
19:25:37 <tflink> proposed #agreed 879612 - AcceptedBlocker - Violates the following F18 final release criteria for using a local iso as an installation source: "The installer must be able to use all supported local and remote package source options"
19:25:51 <akshayvyas> ack
19:26:18 <kparal> ack
19:26:41 <adamw> ack
19:27:03 <tflink> #agreed 879612 - AcceptedBlocker - Violates the following F18 final release criteria for using a local iso as an installation source: "The installer must be able to use all supported local and remote package source options"
19:27:11 <Southern_Gentlem> and if you have /home in the lvm it will want to wipe it
19:27:42 <tflink> #topic (879610) SystemError: (32, 'umount: /run/install/isodir: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))')
19:27:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=879610
19:27:48 <tflink> #info Proposed Blocker, anaconda, NEW
19:29:00 <kparal> similar to above
19:29:06 <kparal> should receive the same treatment
19:29:24 <kparal> +1 blocker
19:29:44 <tflink> proposed #agreed 879610 - AcceptedBlocker - Violates the following F18 final release criteria for using a local iso as an installation source: "The installer must be able to use all supported local and remote package source options"
19:30:42 <akshayvyas> ack
19:30:53 <kparal> ack
19:31:09 <adamw> ack
19:31:37 <tflink> #agreed 879610 - AcceptedBlocker - Violates the following F18 final release criteria for using a local iso as an installation source: "The installer must be able to use all supported local and remote package source options"
19:31:53 * tflink notes that we have 30 minutes remaining until the 3 hour mark
19:32:00 <tflink> #topic (869978) %packages --default doesn't install default system, but minimal one
19:32:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869978
19:32:06 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
19:34:29 <tflink> I'm definitely +1 nth
19:34:38 <tflink> kparal is +1 blocker from the bug
19:34:54 <adamw> what's the criterion for this?
19:35:05 <tflink> not sure we have one that fits nicely
19:35:10 <adamw> +1 nth for sure
19:35:12 <kparal> there is none, afaik
19:35:18 <kparal> it's just our call
19:35:29 <tflink> releasing without %packages --default seems bad
19:35:42 <tflink> unless it gets removed from the docs
19:35:45 <adamw> well, no, we don't do that. if we want it to be a blocker we need to design a generally-applicable criterion we're happy with.
19:35:58 <adamw> we can't just arbitrarily call it a blocker, that's the point of the process.
19:36:31 <adamw> worth noting though that in theory we're supposed to be extending the kickstart criteria based on experience, so this is a bug that could certainly be the basis for a criterion.
19:36:37 <kparal> if we try hard enough we can fudge it as any criterion that is available. but I think that loses the point
19:36:47 <adamw> i'd like to see you try ;)
19:37:21 <tflink> did we ever figure out how ks fits into the criteria outside of the generated ones?
19:37:35 <tflink> ie, do the ks docs need to match what is actually supported?
19:39:21 <adamw> all we really have is the above
19:39:33 <kparal> I think that everything can't be codified into criteria, therefore I don't agree we have to have criteria for every blocker
19:39:36 <kparal> but that's my view
19:39:45 <adamw> we had a mailing list thread on it, and decided to take a minimal criterion, and then write new ones 'based on experience' - i.e. when bugs like this come up, we decide if we want to extend the criteria to cover them
19:39:49 <kparal> the process currently says the opposite, that is true
19:40:08 <tflink> but as the criteria grow, they're getting increasingly more difficult to parse and understand
19:40:18 <tflink> but that's a discussion for another day
19:40:33 <adamw> i would not be against a criterion along the lines of "The --default kickstart parameter must install the same package set as an interactive install where the default package set is not changed", or something like that.
19:40:34 <tflink> I agree with kparal that this should either work or be removed from the docs
19:40:34 <kparal> adamw: but how do you want to codify this issue? it's pretty hard to make it generic
19:40:37 <adamw> yes, please keep that separate.
19:41:14 <tflink> I'd say that all options in the official docs need to work
19:41:18 <kparal> I'm afraid we end up with 100 criteria about different commands in kickstart
19:41:30 <adamw> we could just have a criterion which says that a certain set of kickstart parameters is considered important enough that they should all work as intended
19:41:32 <adamw> kparal: ^^.
19:41:39 <tflink> that might be better
19:41:52 <tflink> the "all documented options" could turn into a problem
19:41:54 <adamw> so, rewind a bit
19:41:58 <adamw> yes, that is too much.
19:42:22 <adamw> who believes that this bug ought to be a blocker, and that the criteria should be amended to cover it?
19:42:26 <adamw> raise your +1s
19:42:53 <kparal> I have lost my faith
19:43:09 <adamw> there's no point amending criteria unless we actually want this bug to block release.
19:43:46 * adamw wonders why everything went quiet.
19:43:54 <kparal> I think it's very very bad to release Fedora with this bug, can't be fixed
19:44:01 <adamw> so is that a +1 ?
19:44:30 <kparal> yes, I'm just afraid I'll have to raise +1 much more than before to be consistent
19:44:30 <tflink> I'm slightly +1
19:44:38 <kparal> *more often
19:44:48 <adamw> kparal: eh? not sure i follow
19:45:04 <adamw> you think if we take this as a blocker we'll have to take lots more blockers? why?
19:45:04 <kparal> sometimes we reject pretty important stuff
19:45:31 <kparal> this one is bad, but not as important as some stuff we sometimes reject
19:45:38 <kparal> anyway, let's go on. I'm +1
19:45:54 <tflink> any -1s?
19:45:57 <adamw> any other votes or is everyone else dead?
19:46:11 <adamw> i'm a bit worried about starting to fiddle with the criteria even provisionally on the basis of three people
19:46:12 <kparal> pschindl disconnected
19:46:26 <adamw> shall we punt it and start a criterion discussion on-list?
19:46:41 <kparal> ok with me
19:46:46 <tflink> proposed #agreed we agree, in principle to propose an provisionally accept a new final release criterion that a reasonable subset of ks options must work
19:46:52 <tflink> that;s better
19:46:59 <tflink> the discussion on list is better, I mean
19:47:02 <kparal> we could start defining some "critical set" of kickstart commands
19:47:11 <kparal> in that thread
19:47:28 <tflink> #action kparal to start thread on test@ about a possible new kickstart release criterion
19:47:45 <kparal> alright
19:48:05 <adamw> rehi pschindl
19:48:27 <kparal> 12 minutes, 1 more bug
19:48:33 <tflink> proposed #agreed 869978 - While this doesn't hit any of the current F18 release criteria, there is discussion about adding a new release criterion to cover a subset of kickstart options. Will re-visit after discussion on test@
19:48:38 <kparal> ack
19:48:45 <pschindl> sry I have some problem with notifications in f18 and freezing of gnome :(
19:49:01 <adamw> propose a blocker? :)
19:49:03 <adamw> ack
19:49:14 <pschindl> tomorrow :)
19:49:18 <tflink> propose a blocker?
19:49:26 <tflink> oh, nvm. I'm being slow
19:49:42 <tflink> moar ack/nak/patch?
19:50:05 <tflink> #agreed 869978 - While this doesn't hit any of the current F18 release criteria, there is discussion about adding a new release criterion to cover a subset of kickstart options. Will re-visit after discussion on test@
19:50:15 <tflink> #topic (864087) wired ethernet defaults to Off in certain situations
19:50:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864087
19:50:15 <tflink> #info Proposed Blocker, anaconda, NEW
19:51:13 <tflink> definitely +1 NTH, assuming I understand
19:51:57 <adamw> oh, christ, another of these.
19:51:57 <kparal> sometimes wired is off by default. depends on the type of install
19:52:12 <akshayvyas> i hit the same same thing in v box
19:52:12 <adamw> we used to get these bugs all the damn time, i thought we'd squelched them finally a few releases back.
19:52:14 <tflink> it's problematic to figure out and/or fix but I'm not sure about blocker
19:52:30 <adamw> there's probably some precedents if we look back a few releases, but i don't recall what we used to do with such bugs off the top of my head
19:52:43 <kparal> I think it should be pretty easy to fix. just one bad "if" in anaconda networking code
19:53:09 <adamw> assuming the 'intended' behaviour is still 'default to dhcp wired on in all cases', I'm at least +1 nth.
19:53:20 <kparal> adamw: it is, I talked to rvykydal
19:53:23 <adamw> ok
19:53:40 <adamw> i guess +1 nth -1 blocker, if i'm going on first principles
19:53:46 <adamw> you can always turn it on after install
19:53:47 <akshayvyas> it happened with me but not sure abt blocker
19:53:49 <pschindl> +1 nth
19:54:09 <tflink> does this affect a livecd before installing?
19:54:14 <kparal> tflink: no
19:54:21 <kparal> tflink: at least i haven't noticed
19:54:25 <kparal> I am not 100% sure
19:54:39 <tflink> if it does, I'd be closer to +1 blocker
19:54:42 <kparal> easy to find out, but it takes a bit of time
19:55:03 <kparal> wanna wait?
19:55:10 <adamw> i'd be really surprised if it did.
19:55:21 <adamw> i'm sure we'd have heard from someone that wired ethernet was down on litd USB.
19:55:22 <kparal> I think it's just anaconda config files badly created
19:55:29 <kparal> right
19:55:42 <adamw> should we assume it only affects post-install, revise if that turns out not to be true?
19:55:52 <kparal> adamw: ok
19:56:19 <tflink> proposed #agreed 864087 - RejectedBlocker, AcceptedNTH - While this can be nonintuitive to discover and figure out post-install, it doesn't directly violate any F18 release criterion and could be fixed post-install. If it turns out that this affects lives pre-install, please re-propose as a blocker
19:56:37 <kparal> ack
19:56:40 <akshayvyas> ack
19:56:47 <pschindl> ack
19:57:13 <tflink> #agreed 864087 - RejectedBlocker, AcceptedNTH - While this can be nonintuitive to discover and figure out post-install, it doesn't directly violate any F18 release criterion and could be fixed post-install. If it turns out that this affects lives pre-install, please re-propose as a blocker
19:57:27 <tflink> OK, I think that's all for today since we're pretty much @ 3 hours
19:57:36 <adamw> sounds good
19:57:40 <tflink> #info Hit the 3 hour mark, stopping the review meeting
19:57:44 <tflink> #topic Open Floor
19:57:47 <tflink> #undo
19:57:47 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x14898ed0>
19:57:55 <tflink> #topic Next Review Meeting
19:58:05 <tflink> any thoughts on when we should continue
19:58:05 * kparal was just about to ask
19:58:16 <kparal> I can't come tomorrow
19:58:17 <tflink> I'm hesitant to say anything other than tomorrow
19:58:27 <tflink> this list is just too big to leave alone for too long
19:58:31 <kparal> monday is fine, after our regular meeting
19:58:45 <tflink> other thoughts?
19:58:51 * adamw will show up whenever
19:58:52 <kparal> it would help a lot if people go through it and re-test it
19:59:06 <adamw> how many more do we have to go through?
19:59:06 * kparal will instruct his slaves,err,interns
19:59:37 <tflink> we got through 14 of 52 proposed blockers and none of the 23 proposed NTH
20:00:03 <adamw> so 2 or 3 more days to get through the rest of the proposed blockers
20:00:14 <tflink> which I think answers the question of tomorrow or not
20:00:21 <tflink> assuming we can find enough people
20:00:22 <kparal> maybe you can plan the time a bit later tomorrow so that more anaconda guys can show up?
20:00:34 <kparal> because it's friday night for us, so I guess no one will come from cz
20:00:47 <tflink> I'm somewhat flexible but I have a hard stop tomorrow afternoon
20:01:15 <tflink> if someone else leads the meeting, that's fine but I have to leave at ~ 20:30 UTC
20:02:15 <tflink> we could always do it earlier in the day if we're OK doing it without adam
20:02:44 * kparal still can't come
20:02:55 <zodbot> Ticket notification - f18finalnicetohave: [Bug 864087] wired ethernet defaults to Off in certain situations <https://bugzilla.redhat.com/show_bug.cgi?id=864087>
20:03:21 <tflink> well, I suspect that we're not going to get much farther on this topic here and now
20:03:37 <adamw> i don't mind if you want to go without me
20:03:40 <kparal> just discuss it with folks from anaconda etc
20:03:41 <tflink> #info we covered 14/52 proposed blockers and 0/23 proposed NTH in today's review meeting
20:04:19 <tflink> #info it's unclear what time is best for a continued review, will discuss with possibly interested parties and send announcement
20:04:45 <tflink> #action tflink to find people and time for the blocker review meeting continuation
20:04:57 <tflink> any other thoughts on this topic before I move to open floor?
20:05:23 <kparal> no
20:05:29 <tflink> #topic Open Floor
20:05:38 <tflink> Anything else to bring up here that can't wait for later?
20:06:01 <Viking-Ice> kparal, not to busy this time for a 10 minute break...
20:06:05 * tflink assumes no and sets fuse for something around 5 minutes
20:06:44 <kparal> Viking-Ice: sorry, I don't get what you mean
20:06:56 <tflink> OK, thanks for coming everyone!
20:07:02 * tflink will send out minutes shortly
20:07:04 <tflink> #endmeeting