17:25:11 <tflink> #startmeeting f18final-blocker-review-1.2
17:25:11 <zodbot> Meeting started Mon Dec  3 17:25:11 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:25:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:25:12 <tflink> #meetingname f18final-blocker-review-1.2
17:25:12 <zodbot> The meeting name has been set to 'f18final-blocker-review-1.2'
17:25:12 <tflink> #topic Roll Call
17:25:37 <txenoo> I see: [OK] Stopped Software RAID Monitor. Takeover ..... Unmounting file systems. Starts unmounting and stops at "Unmounted /sys/kernel/debug"
17:27:06 <tflink> whoops, a little early
17:27:07 <tflink> oh well
17:27:15 * kparal here
17:27:33 * satellit listening
17:28:43 * akshayvyas is here
17:28:59 * jreznik still here but will have to go out with dog soon :(
17:29:30 * adamw jhere
17:29:33 * mkrizek is somewhat here
17:30:50 <mel-> adamw: when i report a bug for
17:31:14 <mel-> adamw: when i report a bug for upgrading f17 to f18beta, what fedora version do I specify for the bug? :)
17:31:29 <adamw> mel-: depends if the bug happens during the f17 part of the process or the f18 part
17:31:34 <adamw> before the reboot, or after?
17:31:42 <tflink> adamw: you beat me to it :)
17:32:40 <tflink> OK, let's get this party started with some always exciting boilerplate
17:32:43 <mel-> adamw: on my system i have triggered the upgrading, went to bed and when i woke up i had an unbootable system.
17:32:55 <tflink> mel-: probably f18 fedup-dracut
17:33:07 <tflink> #topic Introduction
17:33:17 <tflink> Why are we here?
17:33:17 <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:33:23 <tflink> #info We'll be following the process outlined at:
17:33:23 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:33:28 <tflink> #info The bugs up for review today are available at:
17:33:28 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:33:34 <tflink> #info The criteria for release blocking bugs can be found at:
17:33:34 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:33:35 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:33:35 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:33:54 <tflink> #info The current blocker/nth list consists of:
17:33:57 <tflink> #info 44 Proposed Blockers
17:33:57 <tflink> #info 10 Accepted Blockers
17:33:58 <tflink> #info 21 Proposed NTH
17:33:58 <tflink> #info 3 Accepted NTH
17:34:41 <tflink> I'm working off a slightly differently ordered list today - I went through and identified blockers which I thought needed more discussion
17:35:13 <tflink> hopefully the list of more 'obvious' blockers I sent out to test@ will generate enough in-bug discussion to get a bunch of them taken care of
17:35:43 <tflink> mel-: if you file a bug, can you post the bz number here? I'm curious to see what went wrong
17:36:10 <tflink> #topic (882147) 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))')
17:36:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=882147
17:36:15 <tflink> #info Proposed Blocker, anaconda, NEW
17:37:15 <kparal> the description should be inst.repo=hd:vda1:/dvd.iso
17:37:20 * kparal just noticed the typo
17:37:45 <kparal> basically I tried to remove the partition I wanted to install from
17:37:46 <tflink> so, this could be argued to hit "The installer's custom partitioning mode must be capable of the following: ... Rejecting obviously invalid operations without crashing"
17:37:47 <mel-> tflink: of course
17:38:16 * pschindl was waiting on the wrong channel
17:38:35 <tflink> but it could also be argued that trying to delete the source disk is too invalid to block over
17:38:57 <adamw> i'm a bit borderline on blocker here, yeah
17:39:02 <adamw> i could see us waiving this in a go/no-go for sure
17:39:05 <Viking-Ice> me to +1 nth - blocker
17:39:18 <kparal> I wonder what if I tried to resize it?
17:39:24 <jreznik> on go/no-go it would be definitely waived...
17:39:34 <jreznik> but it's definitely +1 nth
17:39:35 <adamw> kparal: damnit, stop breaking stuff. :)
17:39:35 <tflink> kparal: that sounds like an invitation for trouble :)
17:39:45 <adamw> yeah, i'd be +1 nth, though we're kinda early to be worrying about nth.
17:40:01 <tflink> sounds like we're mostly -1 blocker, +1 nth
17:40:06 <tflink> isn't freeze in 1 week?
17:40:10 <kparal> I'm OK with -1 blocker
17:40:21 <jreznik> tflink: freeze is 18th
17:40:30 <kparal> it would deserve +1 nth I think
17:40:54 <jreznik> but - dgilmore is not hapy with it - seems like he prefers freeze next week and if we want to release on jan 8...
17:41:15 <adamw> bit off topic for this meeting anyway, i didn't say we shouldn't vote nth :0
17:41:18 <adamw> so -1/+1?
17:41:25 <kparal> adamw: yes
17:41:28 <jreznik> yep
17:41:31 <Viking-Ice> yup
17:41:56 <jreznik> let's talk about the schedule after the meeting :)
17:42:00 <tflink> proposed #agreed 882147 - RejectedBlocker, AcceptedNTH - While this is an obviously invalid operation that probably should be rejected, it isn't catastropic and is a bit too much of a corner case to block release over
17:42:07 <Viking-Ice> ack
17:42:11 <akshayvyas> ack
17:42:13 <mkrizek> ack
17:42:17 <jreznik> ack
17:42:18 <tflink> #agreed 882147 - RejectedBlocker, AcceptedNTH - While this is an obviously invalid operation that probably should be rejected, it isn't catastropic and is a bit too much of a corner case to block release over
17:42:27 <tflink> #topic (545148) livecd boot from iscsi storage
17:42:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=545148
17:42:27 <tflink> #info Proposed Blocker, dracut, NEW
17:42:58 <tflink> this is another one which seems to be a blocker, technically
17:43:09 <tflink> assuming that iSCSI is a valid remote source
17:43:16 <tflink> but I'm probably -1 blocker on this
17:43:41 <jreznik> and seems it had never worked before... -1 blocker
17:43:43 <kparal> it concerns just live?
17:43:54 <Viking-Ice> I want to punt this one until we get a bit clearer picture of https://www.redhat.com/archives/anaconda-devel-list/2012-December/msg00005.html
17:43:56 <tflink> it sounds like a dracut issue with mounting iSCSI on boot
17:44:29 <tflink> Viking-Ice: I think that's been covered elsewhere and I also don't think that release criterion is related
17:44:29 <Viking-Ice> for consistency
17:44:39 <dgilmore> jreznik: im not happy with it because it gives us 3 days to do the release and fix all blockers
17:44:39 <adamw> how is this 'technically a blocker'?
17:44:41 <tflink> it is iSCSI, yes. but this isn't installing to iSCSI as I'm reading it
17:44:44 <kparal> I see this as a very uncommon use case
17:44:46 <tflink> adamw: remote source
17:44:56 <adamw> precise criterion?
17:45:16 <tflink> "The installer must be able to use all supported local and remote package source options"
17:45:24 <adamw> remote *package source options*.
17:45:37 <adamw> sticking the live image on an iSCSI device and booting from it is not a 'supported remote package source option'.
17:45:55 <adamw> that is referring to stuff you pass as inst.repo , or change on the Installation Source screen. not 'any wacky way you can think of to boot a live image'.
17:45:57 <adamw> -1 blocker, clearly.
17:45:57 <Viking-Ice> tflink, i'm thinking of consistency here if we wont support iscsi in anaconda why should we do it elsewhere
17:46:12 <tflink> Viking-Ice: this bug has nothing to do with anaconda, IIRC
17:46:21 <tflink> s/IIRC/AFAIK
17:46:25 <Viking-Ice> tflink, I know
17:46:39 <tflink> then I'm missing something
17:46:48 <Viking-Ice> I was just trying to explain why we should punt it
17:47:07 <Viking-Ice> if not punt -1 blocker
17:47:12 * adamw still firmly -1 blocker, this looks perfectly clear-cut to me. 'live image on iSCSI' is not a 'remote package source option'.
17:47:13 <mel-> tflink: https://bugzilla.redhat.com/show_bug.cgi?id=883072
17:47:19 <tflink> mel-: thanks
17:47:35 <kparal> -1 blocker from me as well
17:47:35 <mel-> welcome
17:48:38 <nirik> Note: bugzilla.redhat.com outage later today, starting at 17:30EST for 2 hours.
17:48:43 <mel-> tflink: oh damn, i forgot to specify a severity :)
17:48:45 <tflink> adamw: I'm not convinced that this is limited to lives but I'm also not convinced this is common enough to block over
17:48:56 <zodbot> Ticket notification - f18finalnicetohave: [Bug 882147] SystemError: (32, 'umount: /run/install/isodir: target is busy.\n (In some cases useful info about processes that use\n the device is found by lsof(8) or fuser(1))') <https://bugzilla.redhat.com/show_bug.cgi?id=882147>
17:48:58 <Viking-Ice> nirik, what's that in utc ;)
17:49:00 <tflink> nirik: seriously? Did I miss the announcement?
17:49:06 <tflink> oh, EST, not UTC
17:49:22 <nirik> Viking-Ice: let me see... 22:30 I think...
17:50:02 <adamw> tflink: even remote booting a non-live image from iSCSI storage isn't blocker so far as i'm concerned. that's just not what the criterion in question is written to cover, it's not something we've explicitly tested before.
17:50:40 <tflink> proposed #agreed 545148 - RejectedBlocker - This doesn't hit any of the F18 release criteria and thus is rejected as a blocker for F18 final.
17:50:45 <Viking-Ice> ack
17:50:48 <kparal> ack
17:50:49 <jreznik> ack
17:50:52 <adamw> ack
17:50:54 <mkrizek> ack
17:51:04 <akshayvyas> ack
17:51:37 <tflink> #agreed 545148 - RejectedBlocker - This doesn't hit any of the F18 release criteria and thus is rejected as a blocker for F18 final.
17:51:46 <tflink> #topic (874553) rd.debug boot option doesn't log to /run/initramfs/init.log
17:51:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874553
17:51:46 <tflink> #info Proposed Blocker, dracut, ASSIGNED
17:53:00 <kparal> why is this blocker?
17:53:02 <tflink> so, this one is probably not a blocker unless we want to fudge a bit
17:53:09 <tflink> it hinders debugging of dracut
17:53:16 <Viking-Ice> -1 blocker
17:53:21 <jreznik> -1 blocker
17:53:22 <kparal> because of LiveCDs?
17:53:23 <akshayvyas> -1 blocker
17:53:23 <adamw> i don't see any justification in the bug
17:53:37 <tflink> yeah, I probably should have added a comment
17:53:42 <adamw> probably fails the 'if this was go/no-go...' smell test
17:53:45 <adamw> provisional -1
17:53:59 <kparal> -1/+1
17:53:59 * adamw willing to give tflink a chance :)
17:54:15 <tflink> debugging dracut without init.log is a huge PITA
17:54:34 <Viking-Ice> is not the output in the journal ?
17:54:50 <tflink> Viking-Ice: dracut is before journald starts, no?
17:55:10 * tflink isn't really +1 blocker but didn't think it was 100% clear cut
17:55:36 <adamw> seems like it could be fixed with an update for most cases, as kparal points out.
17:55:45 <Viking-Ice> yup
17:55:55 <kparal> except for LiveCDs
17:55:59 <tflink> sure, as long as the installer doesn't have problems booting
17:56:36 <tflink> proposed #agreed 874553 - RejectedBlocker - While this is a hinderance to debugging installed systems and images, it doesn't clearly hit any of the F18 release criteria and is thus rejected as a blocker for F18 final./
17:56:40 <tflink> proposed #agreed 874553 - RejectedBlocker - While this is a hinderance to debugging installed systems and images, it doesn't clearly hit any of the F18 release criteria and is thus rejected as a blocker for F18 final.
17:56:44 <tflink> stray slash at the end
17:56:49 <Viking-Ice> ack
17:56:50 <adamw> ack
17:56:51 <mkrizek> ack
17:56:53 <jskladan_> ack
17:56:56 <pschindl> ack
17:56:58 <tflink> #agreed 874553 - RejectedBlocker - While this is a hinderance to debugging installed systems and images, it doesn't clearly hit any of the F18 release criteria and is thus rejected as a blocker for F18 final.
17:56:58 <jreznik> ack
17:57:08 <tflink> #topic (873817) inkscape packaging bugs prevent install
17:57:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873817
17:57:08 <tflink> #info Proposed Blocker, inkscape, ASSIGNED
17:57:41 <tflink> this is another one that doesn't seem clear cut
17:58:06 <tflink> while inkscape is on the DVD, I don't believe it's part of any of the default DE package groups
17:58:14 <barry_scott> I am testing F18 install process. How do I set up raid? I have got to the Installation Manual Partitioning page.
17:58:22 <adamw> still, we try to not have packaging problems in the release media
17:58:29 <tflink> so if a user installed inkscape from the DVD, anaconda would crash
17:58:46 <adamw> viz the alpha "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install "
17:58:55 <adamw> i'd argue we hit the spirit of that criterion, though not the letter
17:59:01 <kparal> should be a blocker
17:59:22 <adamw> i'd suggest modifying it to add something like 'or any other packaging error causing installation of a package to fail'
17:59:30 <adamw> and +1 blocker on the basis of that mod
18:00:02 <kparal> adamw: actually just saying "no packaging errors" would be fine, conflicts and broken dependencies are packaging errors
18:00:18 <Viking-Ice> +1 blocker
18:00:34 <adamw> kparal: i was thinking something like that too actually - flip it around to say 'no critical packaging errors' and make conflicts and dependency errors just examples
18:00:51 <adamw> but we can thrash out the details on-list
18:01:13 <tflink> proposed #agreed - In spirit, we are OK with modifying the alpha release criterion "There must be no file conflicts or unresolved package dependencies during a media-based (DVD) install" to include more generic packaging errors. The details and final voting will happen on test@
18:01:51 <adamw> barry_scott: quickly - create the partition you want to be RAID, set its mount point, and then click 'Customize...' on the right, and set its device type to RAID, then pick redundancy or striping with the checkboxes
18:01:56 <kparal> patch
18:01:59 <kparal> tflink: AcceptedBlocker
18:02:08 <adamw> i think he was splitting it in two?
18:02:15 <kparal> aha
18:02:20 <barry_scott> adamw: thanks
18:02:26 <kparal> ack then
18:02:33 <tflink> kparal: huh? that was just about the proposed criteria change
18:02:39 <tflink> nvm, I'm slow
18:03:00 <tflink> other ack/nak/patch?
18:03:45 * kparal kicks pschindl jskladan
18:03:54 <jskladan_> ack
18:03:59 <pschindl> ack
18:04:05 <kparal> that's it!
18:04:07 <adamw> ack assuming another one is coming
18:04:07 <jskladan_> sorry, preocupied by food :)
18:04:08 <tflink> #agreed - In spirit, we are OK with modifying the alpha release criterion "There must be no file conflicts or unresolved package dependencies during a media-based (DVD) install" to include more generic packaging errors. The details and final voting will happen on test@
18:04:13 <Viking-Ice> let's just focus on the bug in question and have the release criteria proposal on -.test
18:05:07 <adamw> Viking-Ice: we just have to note that we agree in principle it should be modified, to have a justification for the +1
18:05:24 <tflink> proposed #agreed 873817 - AcceptedBlocker - This violates the modified release criteria mentioned above and is thus accepted as a blocker assuming that the proposed changes go through. Will be rejected if the changed aren't accepted by test@
18:05:39 <adamw> ack
18:05:51 <zodbot> Ticket notification - f18finalnicetohave: [Bug 874486] progress indicator for mediacheck isn't displayed, so users may think the installer is hung <https://bugzilla.redhat.com/show_bug.cgi?id=874486>
18:06:04 <kparal> ack
18:06:06 <jskladan_> ack
18:06:06 <Viking-Ice> ack
18:06:33 <tflink> #agreed 873817 - AcceptedBlocker - This violates the modified release criteria mentioned above and is thus accepted as a blocker assuming that the proposed changes go through. Will be rejected if the changed aren't accepted by test@
18:06:46 <tflink> #topic (873207) No entry in grub2 menu for windows8 in dual boot setup install TC7
18:06:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873207
18:06:51 <tflink> #info Proposed Blocker, os-prober, NEW
18:07:35 <tflink> if I'm understanding this correctly - the issue is that a windows entry isn't automatically added to the grub menu
18:08:05 <tflink> which I don't think is a blocker - it makes dual-booting more of a pain but this doesn't block anyone from dual-booting
18:08:13 <Viking-Ice> it hits "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working "
18:08:17 <kparal> tflink: so how do you boot?
18:08:23 <Viking-Ice> +1 blocker
18:08:38 <tflink> kparal: modify grub in fedora after install
18:08:40 <kparal> I'd be +1 blocker for Win 7. Win 8 coverage is extremely small now, I can imagine we reject it
18:08:43 <tflink> like the "good old days"
18:09:05 <kparal> tflink: then we don't have to have any criteria at all, because everything can be modified
18:09:08 <kparal> manually
18:09:23 <tflink> how does this prevent you from dual booting?
18:09:32 <Viking-Ice> I don think it's wize to start chasing down windows version
18:09:36 <kparal> " install a bootloader which can boot into the Windows installation" is pretty clear
18:09:46 <tflink> ah, I missed that part
18:10:06 <tflink> too much bz in one day makes the head spin
18:10:42 <kparal> still, there is one more change for Win8, you can use UEFI menu to boot it. does it still support BIOS computers?
18:10:43 <tflink> the bootloader can boot into windows, but I'm splitting hairs here
18:10:50 <barry_scott> adamw: Customise allows me to choose LVM or Standard Partition, no sign or RAID. (VMware is cutting off some of the screen to the right maybe what I need to click is there?)
18:11:27 <adamw> barry_scott: not sure, sorry. oh, RAID will be disallowed for some partitions (/boot and swap, I think)
18:11:37 <barry_scott> adamw: If this is documented I'll happily read the docs
18:11:49 <jreznik> kparal: at least Win8 certified does not support BIOS but I hope it's installable on the older ones
18:11:51 <barry_scott> RAID works great for /boot we use it all the time
18:11:57 <kparal> if UEFI is required for Win8, it might be OK, because there will be a boot menu, even though not in grub
18:12:00 <adamw> yeah, this criterion was really written for BIOS
18:12:16 <adamw> UEFI isn't required for Win8, but a test of a UEFI install is completely different from a BIOS test
18:12:33 <adamw> we can't conclude from a UEFI test that a BIOS case is buggy.
18:12:42 <kparal> right
18:13:00 <kparal> I wonder whether someone has Win8 to test
18:13:16 <adamw> not here
18:13:22 <Viking-Ice> not me
18:13:24 <adamw> rh may have some kind of site license, i guess we could check
18:13:37 <adamw> i'm -1 on this specific bug, it's very much a question of design and UEFI dual boot is still pretty corner case-y
18:13:53 <jskladan_> /me hates laggy internet connections...
18:14:18 <Viking-Ice> well if not a blocker the criteria needs to be adjusted or droppe
18:14:19 <Viking-Ice> d
18:14:20 <tflink> other thoughts?
18:14:28 <kparal> adamw: yes, if we talk just about UEFI that sounds OK. I'm still worried about BIOS mode, but we can't test that easily
18:14:28 <tflink> I'm seeing +2/-2 ATM
18:15:08 <Viking-Ice> I'm only +1 because it's clearly in the criteria
18:15:15 <adamw> kparal: oh, i'd like to know if it works too, but this bug gives us absolutely no data on this. it's very clear from the comments that UEFI is completely different to BIOS here
18:15:16 * jreznik is not sure and probably more discussion on this criteria should go on...
18:15:26 <Viking-Ice> in general I'm against having this in the criteria et all ( dualboot with windows )
18:15:41 <Viking-Ice> mean having this criteria et all
18:16:03 <Viking-Ice> so people that are for it will just have to suck it up and have us block the release ;)
18:16:10 <adamw> Viking-Ice: well, as far as the criterion is worded, it's not a clear +1. if you do a BIOS install of winxp and a BIOS install of fedora, it works, i've tested that. so the installer certainly 'can'.
18:16:17 <kparal> I'm +1/-1. I'll ask Spice guys whether they have a win8 license
18:16:19 <adamw> i love these ambiguous criteria where we can read a single success as a pass. :P
18:16:24 <kparal> err
18:16:26 <kparal> -1/+1
18:16:44 <adamw> but if you like, i could propose that we modify the criterion to specify BIOS, as it's written to BIOS expectations
18:16:57 <jreznik> so punt and ask someone with win 8 to give us more data?
18:17:10 <jreznik> btw from linked bug reports it seems like patches does exist
18:17:20 <kparal> I'd decide based on UEFI and ask to re-propose if someone finds it broken also with BIOS
18:17:42 <tflink> ok -3/+1
18:17:52 <jreznik> kparal: well it sounds reasonable
18:18:11 <jreznik> if you hit it with BIOS, you're screwed up, with UEFI, you're not (probably)
18:18:20 <barry_scott> Is my next step to raise a bug on the no RAID in installer?
18:18:25 <adamw> jreznik: eh? no. you can't hit this bug with BIOS. it is entirely UEFI specific.
18:18:30 <Viking-Ice> I think we should drop this criteria altogether since we cant be chasing other OS and block the release due to their changes ;)
18:18:36 <adamw> barry_scott: i'd ask in #anaconda what's going on in your case
18:18:49 <jreznik> adamw: just following what kparal said...
18:18:50 <adamw> still, it sounds like we're solidly -1 on this, for whatever personal reasons everyone has. :)
18:18:52 <tflink> any other votes?
18:18:53 <barry_scott> adamw: thanks will do
18:19:04 <tflink> we're still -3/+1 unless I missed a vote somewhere
18:19:04 <adamw> jreznik: well if it's broken with BIOS that would be a different bug, not this one.
18:19:23 <jreznik> ok, so -1 blocker
18:19:37 <tflink> -4/+1
18:20:00 <adamw> that sounds like enough to move on
18:20:18 * Viking-Ice notes I'm only +1 on criteria principal in spirit I'm -1
18:20:35 * jreznik would like to see such release criteria for Windows too :)
18:20:56 <tflink> proposed #agreed 873207 - RejectedBlocker - The dual-boot with windows criterion was written for BIOS systems and the UEFI/win8 case is different. If it turns out that the BIOS case is affected, please re-propose as a blocker
18:21:06 <jreznik> ack
18:21:13 <kparal> ack
18:21:13 <jreznik> or maybe remove that BIOS part?
18:21:16 <jskladan_> ack
18:21:26 <jreznik> as it will be different bug as adamw pointed out
18:21:31 <adamw> ack
18:21:54 <tflink> proposed #agreed 873207 - RejectedBlocker - The dual-boot with windows criterion was written for BIOS systems and the UEFI/win8 case is different. If it turns out that the BIOS case is affected, please file a new bug and propose it as a blocker
18:21:59 * tflink assumes that the acks hold
18:22:05 <tflink> #agreed 873207 - RejectedBlocker - The dual-boot with windows criterion was written for BIOS systems and the UEFI/win8 case is different. If it turns out that the BIOS case is affected, please file a new bug and propose it as a blocker
18:22:18 <tflink> #topic (867770) anaconda GUI becomes unresponsive
18:22:18 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=867770
18:22:19 <tflink> #info Proposed Blocker, anaconda, MODIFIED
18:22:40 <kparal> +1 blocker
18:23:35 <adamw> i'm pretty close to +1 blocker on this, yeah. it's pretty annoying and confusing.
18:23:39 <tflink> I'm +1 blocker in spirit but I'm not sure about the criterion to use
18:23:53 <adamw> also clicks that happen while it's 'frozen' get picked up, so you could theoretically do something bad by clicking in the same place a few times...
18:24:13 <adamw> oh, wait, this is a slightly different one
18:24:14 <adamw> sorry
18:24:25 * satellit are they waiting for resolving software before trying this?
18:24:57 <adamw> can we treat this essentially as a crash in the installer? at least for the cases where it doesn't unstick on its own?
18:25:12 <adamw> this should be marked in ON_QA i think, since 18.32 is built
18:25:30 <adamw> oh, 18.34 even.
18:25:45 <tflink> yeah, .33 was skipped due to some build problems - I didn't ask for specifics
18:27:03 <Viking-Ice> +1 blocker
18:27:03 <adamw> i guess i'd say +1, treat it as a crasher.
18:27:22 <tflink> criterion?
18:27:32 <Viking-Ice> The installer must be able to complete an installation using all supported interfaces
18:27:37 <adamw> whatever we usually use for install crashers?
18:27:38 <Viking-Ice> we,
18:27:39 <jreznik> pick one :)
18:27:42 <adamw> yeah, a conditional violation of something like that
18:27:55 <adamw> on the basis that enough people have seen it
18:27:56 <Viking-Ice> mean well any installer must complete ( if it freezes it violates that ; ) )
18:28:01 <adamw> right.
18:28:04 <tflink> "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"?
18:28:22 <Viking-Ice> yup sounds appropriate
18:28:29 <zodbot> Ticket notification - commonbugsrss: [Bug 873207] No entry in grub2 menu for windows8 in dual boot setup install TC7 <https://bugzilla.redhat.com/show_bug.cgi?id=873207>
18:28:56 <adamw> good enough
18:29:24 <tflink> proposed #agreed 867770 - AcceptedBlocker - Violates the following F18 final release criteria (in spirit) if a user re-enters the storage spoke after reclaiming space: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
18:29:30 <tflink> is that too long?
18:29:51 <Viking-Ice> it's fine ack
18:30:14 <kparal> ack
18:30:17 <jskladan_> ack
18:30:36 <adamw> ack
18:30:54 <jreznik> ack
18:31:32 <tflink> #agreed 867770 - AcceptedBlocker - Violates the following F18 final release criteria (in spirit) if a user re-enters the storage spoke after reclaiming space: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
18:31:46 <tflink> #topic (879030) pungi strips langpacks metadata from comps, breaks langpacks installation for DVD
18:31:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=879030
18:31:51 <tflink> #info Proposed Blocker, yum, NEW
18:32:19 <adamw> +1 blocker - comment #2, and web browsing is in the critpath
18:32:23 <adamw> with this bug, you don't get the firefox translations
18:32:40 <adamw> so, criterion is violated.
18:32:50 <Viking-Ice> this could be fixed via update ?
18:32:51 <kparal> +1
18:32:57 <kparal> no
18:33:08 <kparal> you can install the translations manually
18:33:13 <adamw> Viking-Ice: no, the langpacks aren't re-calculated on update, only on package re-install, which you'd have to do manually
18:33:22 <Viking-Ice> +1
18:33:34 <kparal> so actually firefox update could download the translations
18:33:46 <kparal> the same for libreoffice etc
18:34:02 <adamw> eh? we just said it doesn't do that
18:34:15 <kparal> well, update vs reinstall
18:34:18 <kparal> both work, right?
18:34:23 <adamw> i don't *think* so
18:34:31 <adamw> aiui 'yum update firefox' won't add the langpack, but 'yum reinstall firefox' will
18:34:37 <kparal> ah
18:34:40 <adamw> we should check though i guess - if an update fixes it, that's less of a problem
18:35:00 <kparal> still the user would get untranslated apps for quite some time
18:35:11 <kparal> hunspell and similar might not be updated frequently
18:35:17 <adamw> well, we could just ship an update for every package with a langpack to force the reinstall, in theory
18:35:32 <kparal> adamw: but if someone installs a week later...
18:35:33 <adamw> should we make it acceptedblocker assuming 'yum update' doesn't add the translations, punt if it does?
18:35:37 <adamw> i can check that async
18:35:48 <adamw> kparal: net install works fine, bug affects dvd only.
18:36:04 <adamw> not sure what happens if you do DVD install with the update repo enabled :)
18:36:17 <tflink> proposed #agreed 879030 - AcceptedBlocker - Violates the following F18 final release criteria for DVD installs and can't be fixed with an update post-isntall without reinstalling packages: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
18:36:27 <kparal> I think it should be a blocker in both cases
18:36:29 * tflink will edit
18:36:34 <tflink> s/will/can
18:36:42 <adamw> i'll ack that, and i can re-propose the bug if it turns out to be wrong
18:36:42 <Viking-Ice> ack
18:36:45 <kparal> ack
18:36:47 <adamw> i'm testing in the background
18:36:48 <pschindl> ack
18:36:48 <jskladan_> ack
18:37:03 <jreznik> ack
18:38:34 <tflink> #agreed 879030 - AcceptedBlocker - Violates the following F18 final release criteria for DVD installs and can't be fixed with an update post-isntall without reinstalling packages: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
18:38:45 <tflink> #topic (860525) dracut-pre-pivot[272]: mount: wrong fs type, bad option, bad superblock on /var/lib/nfs/rpc_pipefs,
18:38:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860525
18:38:50 <tflink> #info Proposed Blocker, dracut, NEW
18:39:30 <tflink> according to c#11, this could affect NFS installs
18:40:17 <kparal> tflink: but it seems to affect installed system
18:40:20 * kparal is confused
18:40:47 <tflink> so am I, I probably should have left this off the list
18:40:50 * adamw reads
18:41:15 <Viking-Ice> looks like we need more data
18:41:21 <Viking-Ice> "This would prevent possible NFS install errors."
18:41:27 <adamw> hey, now I'm confused too!
18:41:34 <Viking-Ice> install and install errors are two different thing ;)
18:41:38 <adamw> yeah, the first few comments seem to be talking about a post-install case, then I don't know what Harald means.
18:41:48 <adamw> i think we can agree, we're all confused. =)
18:41:50 * jreznik is confused for the second time, already read this bug tmrw in the morning
18:42:50 <kparal> punt and wait for more info
18:43:15 <Viking-Ice> I just ping harald so let's punt for now and revisit if/when he responds
18:43:17 * jreznik is asking harald
18:43:25 <tflink> proposed #agreed 860525 - We still don't understand exactly how this is a release-blocking issue or which criteria it impacts. Ask for more info and revisit later
18:43:34 <jreznik> ack
18:43:44 <kparal> ack
18:43:46 <jskladan_> ack
18:43:51 <tflink> #agreed 860525 - We still don't understand exactly how this is a release-blocking issue or which criteria it impacts. Ask for more info and revisit later
18:43:52 <Viking-Ice> ack
18:44:02 <tflink> #topic (861219) Switching to discret GPU render system unusable
18:44:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=861219
18:44:02 <tflink> #info Proposed Blocker, xorg-x11-drv-nouveau, NEW
18:44:36 <tflink> this is pretty clear, just didn't go out on the list due to missing info
18:44:39 <tflink> -1 blocker from me
18:44:45 <Viking-Ice> -1 blocker
18:44:52 <jreznik> -1 blocker, see my comment in bug
18:45:19 <adamw> -1, yeah, switcheroo is all still experimental and unsupported.
18:45:28 <tflink> proposed #agreed 861219 - RejectedBlocker - This doesn't hit any of the F18 release criteria as it doesn't impede basic operation. Thus, is rejected as a blocker for F18 final
18:45:31 <adamw> ack
18:45:32 <Viking-Ice> ack
18:45:35 <jreznik> ack
18:45:38 <tflink> #agreed 861219 - RejectedBlocker - This doesn't hit any of the F18 release criteria as it doesn't impede basic operation. Thus, is rejected as a blocker for F18 final
18:45:47 <tflink> #topic (873144) pressing Esc kills plymouth screen
18:45:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873144
18:45:48 <tflink> #info Proposed Blocker, plymouth, NEW
18:46:42 <tflink> bah, I'm trying to do too many things @ the same time again
18:46:53 <adamw> i'm not sure that *this* is quite the right bug to block on
18:46:55 <Viking-Ice> ? this is intended behaviour afaik
18:47:05 <tflink> either way, this might be fixed (I haven't tried in new plymouth) but I'm not sure
18:47:10 <adamw> i'd be happier if we blocked on having some kind of progress behind plymouth. that would appear to make more sense.
18:47:16 <Viking-Ice> yeah
18:47:17 <adamw> but blocking on 'esc makes plymouth go away' seems wrong.
18:47:23 <Viking-Ice> yup
18:47:25 <tflink> this bug isn't well named
18:47:32 <kparal> tflink: I don't understand why this is +1 blocker from you, but the lack of progress bar is -1
18:47:58 <tflink> I guess I just see log info as more important
18:48:07 <tflink> but in reality, I'd be OK with one or the other
18:48:27 <kparal> "My concern is if someone thinks that the upgrade didn't actually start and reboots the machine during upgrade; borking the system either permanently or requiring a non-trivial recovery process."
18:48:35 <kparal> that applies for missing progress bar as well
18:49:11 <adamw> if we make this the bug for 'we need to ensure something is indicating "update in progress" whether plymouth is showing or not', that's fine by me
18:49:17 <adamw> but right now it's not clearly that
18:49:19 <Viking-Ice> progress bar ( or some other indication upgrading is (still) taking place ) text/gui mode is necessary for final
18:49:26 <tflink> kparal: like I said, "in reality id be OK with one or the other"
18:49:56 <adamw> btw, i think ray may be thinking about offline updates rather than fedup upgrades with comment #8. but that's just a semi-educated guess
18:50:09 <tflink> I wonder if using 883075 as the blocker would be best
18:50:15 <tflink> even though I closed it as a dupe of this
18:50:23 <Viking-Ice> should we just nack this one and  create a new one that explicitly states what we are after?
18:50:35 <tflink> (source of the 'doing too many things at the same time comment')
18:50:52 <adamw> Viking-Ice: either that, or punt
18:50:57 <adamw> either way, give tflink a bit of time to clean it up nice
18:51:20 <kparal> I think we should decide whether we want progress bar to block, and treat this one the same
18:51:20 <tflink> are we leaning towards reject or punt?
18:51:42 <adamw> i think we agree in principle that we want a bug that clearly says 'we need to have a progress indicator in all cases' and that will be a blocker
18:51:45 <Viking-Ice> I think we all are on the same page we ant progress bar
18:51:49 <Viking-Ice> mean want
18:51:54 <adamw> but we don't want to just sign that off in this meeting, we'd rather get it cleaned up first then sign it off
18:51:54 <kparal> adamw: we have that one
18:52:11 <adamw> if there's already a bug for that, make sure it's nominated as a blocker, and close this as a dupe of that.
18:52:12 <kparal> adamw: https://bugzilla.redhat.com/show_bug.cgi?id=879295
18:52:25 <kparal> adamw: you both voted -1 in it
18:52:26 <tflink> what about using 883075?
18:52:44 <tflink> or do we want to file a new bug?
18:53:01 * kparal is confused. what's wrong with 879295?
18:53:02 <adamw> i think i misread that one
18:53:20 <adamw> either way, can we just agree to clean this up and bring it up at the next meeting with a coherent story?
18:53:25 <adamw> it seems too confused to sort it out here
18:53:27 <tflink> sure
18:53:31 <adamw> we already wasted a lot of time
18:53:47 <Viking-Ice> hm 883075 looks like a good candidate
18:54:01 <Viking-Ice> to accept and file rest as dupes of that one
18:54:11 <tflink> #info there are several bugs related to this issue and the story isn't 100% clear. it needs to be cleaned up and discussed later
18:54:16 <tflink> Viking-Ice: they aren't dupes, though
18:54:24 <kparal> there are two different issues: 1) missing progress bar 2) plymouth killed on key press
18:54:27 <tflink> there are just multiple issues affecting fedup status during upgrade
18:54:50 <kparal> 1) is 879295 and 2) is 873144
18:55:01 <kparal> it's really simple
18:55:04 <Viking-Ice> we should just have a blinking text that says still upgrading ;)
18:55:39 <tflink> #action tflink to clean up fedup upgrade status bugs and propose one as a blocker for F18 final
18:56:21 <tflink> #info we agree in principle that some status indication is needed during upgrade before F18 final is released. however, we don't want to accept anything as release blocking without being more specific on what the solution we're expecting is
18:57:03 * jreznik likes it
18:57:04 <tflink> proposed #agreed 873144 - The situation here isn't 100% clear and needs to be cleaned up before farther discussion. Will re-visit when the upgrade status issue has been cleaned up
18:57:10 <Viking-Ice> ack
18:57:10 <adamw> kparal: plymouth killed on key press is not an 'issue'. it's what's meant to happen. the issue is that there's no kind of progress indication *behind* plymouth.
18:57:15 <adamw> ack
18:57:17 <jreznik> ack
18:57:26 <tflink> #agreed 873144 - The situation here isn't 100% clear and needs to be cleaned up before farther discussion. Will re-visit when the upgrade status issue has been cleaned up
18:57:40 <tflink> #topic (881670) Provide fedup hook to add x-systemd.device-timeout=0 to mount options for encrypted file systems that need a passphrase from the user
18:57:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881670
18:57:45 <mel-> tflink: btw, i don't know if i pressed esc. I think not.
18:57:45 <tflink> #info Proposed Blocker, systemd, NEW
18:57:54 <Viking-Ice> +1 blocker
18:58:09 <tflink> mel-: sorry about closing your bug earlier - like I said, I'm trying to do too many things @ the same time
18:58:27 * tflink assume that you were the one who filed 883075
18:58:39 <mel-> tflink: that's fine! just trying to add info.
18:58:58 <Viking-Ice> "For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using all officially recommended upgrade mechanisms. The upgraded system must meet all release criteria "
18:59:10 <kparal> adamw: I think the word "killed" caused the misunderstanding. nevermind now
18:59:11 <mel-> tflink: i think me pressing keys (like e.g. virtual console switching) was a reaction to not seeing any messages.
18:59:23 <Viking-Ice> new bug people ;)
18:59:36 <tflink> it is and it isn't
18:59:47 <jreznik> btw. is this one the three hours long or one hour long meeting - my dog really wants to go out :)
19:00:03 <tflink> this could be a contributing factor to the issues that mel- hit
19:00:30 <kparal> are we talking about 881670 now?
19:00:44 <tflink> yeah, I just read your comments and realize that I misunderstood
19:00:46 <Viking-Ice> I am
19:01:06 <Viking-Ice> we moved to that bug?
19:01:23 <adamw> so long as 861123 is -1, this is -1.
19:01:34 <adamw> jreznik: i think we're on 2-3 hours today.
19:01:40 <kparal> adamw: no
19:01:59 <kparal> adamw: 861123 is -1, because fstab was already adjusted and now it's just systemd bug, that can be fixed by an update
19:02:16 <kparal> in 881670 fstab was not adjusted and it can't be fixed with an update
19:02:16 <adamw> well, that's a point. but i was -1 on that anyway.
19:02:29 <jreznik> adamw: ok, I'll be back in half hour... bakuse is getting crazy...
19:02:30 <adamw> we've never guaranteed to clean things up super nicely on upgrade.
19:03:05 <kparal> adamw: I don't see a technical problem here. you just say we don't care
19:03:05 <Viking-Ice> jreznik, 2 hours is fine for me I'm heading home from work after this one
19:03:20 <Viking-Ice> ( 19:00 ) here ...
19:04:11 <tflink> I'm still slightly confused - is the bug that all upgrades w/ encrypted disks will fail post-upgrade?
19:04:18 <adamw> kparal: we don't decide blockers based on technical issues, but quality expectations.
19:04:19 <kparal> I don't see any reason why people should end up with dracut shell when they don't type their password fast enough
19:04:23 <Viking-Ice> I'm leaning towards +1 blocker here this does affect every upgrade with encrypted partition right?
19:04:31 <adamw> there's no technical problem with 'fixing' this, but i'm not convinced it's a bad enough bug that we need to block release for it.
19:04:44 <kparal> tflink: they will fail on every boot if you don't type your password in time (1-2 minutes)
19:05:02 <kparal> (after upgrade)
19:05:03 <adamw> besides, if we're talking about upgrades, then we can still fix stuff with updates, yes? if the hook ships as part of the systemd package, we could theoretically do a post-release systemd update that adds the hook...
19:05:26 <kparal> this is fedup hook we talk about
19:05:31 <adamw> kparal: i'm not saying the current behaviour is correct, just that i'm not convinced fixing it is a release blocker.
19:05:35 <adamw> kparal: i know.
19:05:37 <kparal> fedup-dracut to be precise
19:05:44 <adamw> but still, is there anything saying we can't update the hooks?
19:06:05 <kparal> Lennart says in bug 861123 it can't be done
19:06:06 <Viking-Ice> adamw, the risk here is that people turn on upgrade and walk away come back and be left on a shell prompt
19:06:06 <tflink> in fedup?
19:06:21 <kparal> otherwise they would do it as part of systemd update
19:06:32 <kparal> that's why he requested anaconda folks to do it
19:06:35 <Viking-Ice> adamw, for the general case of your not fast enough to type your password on I'm -1 blocker
19:06:44 <Viking-Ice> -1 nth
19:07:23 <Viking-Ice> since in that usecase  you are powering up your computer and are next to it
19:07:38 <Viking-Ice> at it I mean
19:07:48 <kparal> real world example, from the time pschindl upgraded to F18, I see dracut shell on his screen all the time. he starts/reboots the computer and goes for tea
19:07:53 <jreznik> could be sensible message shown in dracut shell?
19:08:06 <adamw> dunno.
19:08:11 <kparal> Viking-Ice: if you hit Reboot and it takes a lot of time, you go for a sandwich
19:08:23 <tflink> if this was the last blocker left in go/no-go, would we slip release for this?
19:08:23 <Viking-Ice> steak I go for a steak! ;)
19:08:31 <kparal> tflink: yes
19:08:35 <Viking-Ice> tflink, yes
19:08:47 <tflink> Viking-Ice: i thought you were -1 blocker
19:08:57 <kparal> I'm also confused about that
19:08:59 <jreznik> tflink: I'd say no... for go/no-go
19:09:18 <jreznik> but yeah, at least a sensible message makes sense
19:09:48 <Viking-Ice> tflink, +1 for the upgrade case  ( 881670 ) -1 ( 861123 none upgrade )
19:10:08 <kparal> we're now talking about 881670
19:10:24 <kparal> so +1 from Viking-Ice
19:10:57 <kparal> I can't imagine more severe regression then breaking boot
19:11:11 <kparal> *than
19:11:26 <tflink> sure but unless I'm misunderstanding something, this isn't really breaking boot
19:11:35 <kparal> comment #1 says the criteria
19:11:40 <tflink> a PITA and something that probably shouldn't be done, sure
19:11:53 * jreznik agrees with tflink
19:12:04 <adamw> yes, how is this breaking boot?
19:12:09 <adamw> can you not just reboot and try again?
19:12:24 <tflink> I really don't understand how this is different from the install case
19:12:25 <kparal> adamw: so how do you reboot if you don't know magic commands? hard reboot, the only option
19:12:27 <kparal> is that safe?
19:12:42 <adamw> true.
19:13:41 <adamw> i dunno, i accept the upgrade case is more a problem than the general case, but i'm still not convinced of blockeriness.
19:13:44 <kparal> and it can't be fixed with an update. sorry, but this one is an obvious blocker for me
19:13:45 <adamw> maybe we need more perspectives?
19:14:26 <kparal> ask lennart whether there is any possible way to fix it afterwards, if it is not fixed by the time of fedora 18 release
19:14:28 <Viking-Ice> in the case of upgrade-ness it's an clear blocker to me
19:15:05 <tflink> I'm thinking punt
19:15:23 <tflink> I'm pretty sure that reboot would be safe during upgrade for encrypted /
19:15:31 <tflink> but I'm not so sure about encrypted /home only
19:15:47 <kparal> tflink: good one
19:15:54 <kparal> the / is already mounted rw
19:15:58 <kparal> isn't it
19:16:15 <tflink> the upgrade can't start if / isn't mounted
19:16:28 <kparal> tflink: this is not about the upgrade process
19:16:37 <kparal> this is about every boot after upgrade is finished
19:17:08 <kparal> every computer start up forever, since the time you upgraded
19:17:14 <tflink> fair enough
19:17:19 <adamw> but didn't you just say the upgrade case is the most important one, because that's when you fire it and forget
19:17:20 <adamw> ?
19:17:20 <jreznik> ok, punt today and ask for more opinions + possibilities?
19:17:43 <kparal> adamw: I'm afraid I can explain it properly, because you still don't get it
19:17:44 <kparal> :/
19:18:06 <kparal> this has to be fixed in fedup, because if it is not, it will affect every computer boot afterwards
19:18:13 <tflink> I think I understand the post-upgrade issue. I just disagree that it's a blocker
19:18:13 <kparal> fstab has to be modified during upgrade
19:18:17 <adamw> kparal: i know that.
19:18:26 <Viking-Ice> Mexican standoff
19:18:36 <Viking-Ice> 2 +1 vs 2 -1
19:18:37 <adamw> i am referring to "<Viking-Ice> adamw, the risk here is that people turn on upgrade and walk away come back and be left on a shell prompt"
19:18:45 <adamw> "<kparal> real world example, from the time pschindl upgraded to F18, I see dracut shell on his screen all the time. he starts/reboots the computer and goes for tea"
19:18:54 <adamw> "<kparal> Viking-Ice: if you hit Reboot and it takes a lot of time, you go for a sandwich"
19:18:57 <tflink> those are two different situations
19:19:02 <kparal> adamw: that the consequence, because fedup will auto-reboot, and it will time out afterwards
19:19:05 <tflink> one is during upgrade, the other is after
19:19:08 <adamw> you keep citing the case where you do an upgrade, because in that case, you hit the button and walk away.
19:19:11 <adamw> tflink: *I KNOW*
19:19:25 <adamw> but the argument that the upgrade case is important because you are likely to fire the upgrade and then walk away keeps coming up
19:19:27 <kparal> this is the same issue
19:19:34 <adamw> that argument does not apply post-upgrade, because you aren't likely to do that.
19:19:39 <adamw> unless, of course, you're doing an offline update...
19:20:04 <adamw> my point is that the bug still exists post-upgrade, but you can't use the argument that people are going to trigger a reboot and then walk away, at least not so clearly.
19:20:14 <kparal> why not?
19:20:18 <adamw> because why would they?
19:20:27 <tflink> and even if they did, they can reboot
19:20:28 <kparal> install updates, hit Reboot, turn around and talk to someone
19:20:31 <Viking-Ice> for steak I would for a steak ;)
19:20:32 <kparal> in another room perhaps
19:20:34 <adamw> you provided a plausible scenario where someone would do so: an OS upgrade via fedup. fine. I accept that.
19:20:44 <adamw> but that scenario isn't a post-upgrade scenario.
19:21:07 <kparal> it's the same problem
19:21:13 <adamw> it is the same technical bug. yes.
19:21:26 <adamw> we do not evaluate blocker status based on 'what is the code that is broken', we evaluate it based on user impact.
19:21:38 <adamw> anyhow, i think we have all the issues clearly enough now...
19:21:45 <kparal> yes, and all of that is caused by 881670
19:21:54 <adamw> i know.
19:22:06 <kparal> I think we should let it rest :)
19:22:10 <kparal> for a while
19:22:13 <adamw> yeah
19:22:35 <kparal> #propose punt
19:22:50 <tflink> proposed #agreed 881670 - We need more information on potential solutions to this class of propblems before deciding on blocker status, will re-visit later
19:23:03 <kparal> ack
19:23:03 * jreznik already said that 6 minutes ago :)
19:23:04 <Viking-Ice> ack with bacon
19:23:17 <jreznik> ack with steak (/me is on diet now...)
19:23:23 <pschindl> ack
19:23:45 <kparal> ack
19:23:56 <tflink> #agreed 881670 - We need more information on potential solutions to this class of propblems before deciding on blocker status, will re-visit later
19:23:58 <Viking-Ice> jreznik,  I should go on a diet but fucking I only live once anyway ;)
19:24:11 <adamw> ack
19:24:13 <tflink> #topic (868558) anaconda needs to tell yum what's a URL and what's a mirrorlist
19:24:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868558
19:24:18 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
19:24:37 <Viking-Ice> well here I bid farewell and leave you to it
19:24:41 <Viking-Ice> later
19:24:55 <jreznik> Viking-Ice: see you!
19:25:01 <adamw> cya viking
19:25:48 <jreznik> kparal: so it's now only about "The checkbox description still needs adjustment"?
19:26:00 <kparal> I don't know
19:26:14 <kparal> tflink: adamw: were your votes about GUI or about the issue as a whole?
19:26:37 <kparal> I think I got confused a bit in there
19:27:06 <kparal> I'm +1 blocker for fixing the issue (it's already fixed, just not in stable), I'm not so sure about GUI labels
19:27:08 <tflink> the issue as a whole
19:27:29 <adamw> the failure to be able to use mirrorlists at all is obvious +1
19:27:35 <adamw> the 'current' state is a bit funny
19:27:41 <kparal> tflink: so it the checkbox labels stays incorrect (mirror instead of mirrorlist), do we still want to block on that?
19:27:44 <kparal> *if
19:27:50 <adamw> what's left is just UI fail, but it's kind of bad UI fail: i don't think anyone's going to realize that label should say 'mirror list'
19:27:57 <adamw> unless they remember it from oldui, and i didn't
19:28:15 <adamw> as it is, i think it might make things *worse* - i mean, if you enter a direct mirror URL and then check the box, like it tells you to, it'll break taht!
19:28:27 <adamw> so though i said "UI niggles aren't blocker"...this one might be
19:29:13 <tflink> yeah, at least +1 nth on the UI
19:29:16 <adamw> it's like a self-destruct button with a label saying 'PRESS HERE TO PREVENT SELF-DESTRUCT'
19:29:23 <adamw> not helpful :)
19:29:37 <kparal> +1 nth for sure
19:30:08 <adamw> definite nth, i'm close to blocker even just for the label. it'd really suck to have that in there.
19:30:11 <tflink> but is the UI issue a different bug?
19:30:23 <kparal> it's covered in the same bug report
19:30:55 <tflink> that's arguable
19:31:14 <tflink> you can specify a mirror list
19:31:25 <kparal> I wouldn't object to +1 blocker, but it annoys me that breaking boots might not end up a blocker, but this could
19:31:53 <tflink> I'm not saying that it isn't a blocker, just wondering if it needs to be a new bug
19:32:11 <adamw> ideally yeah it should be. i'll split it out.
19:32:19 <adamw> shall we just for now say that this bug as written is clearly +1 blocker?
19:32:21 <adamw> since it is.
19:32:26 <kparal> yes
19:32:32 <adamw> i can separate out the UI issue and propose it separately if it doesn't get a quickfix.
19:32:38 <kparal> adamw: but move it to VERIFIED then
19:32:46 <adamw> right, i'll do the cleanup.
19:32:57 <kparal> (868558)
19:33:07 <jreznik> ok
19:33:11 <tflink> proposed #agreed 868558 - AcceptedBlocker - Violates the following F18 final release criterion for mirror lists: "The installer must be able to use all supported local and remote package source options"
19:33:18 <kparal> ack
19:35:20 <tflink> other ack/nak/patch?
19:35:55 <kparal> pschindl: say ack
19:36:47 <adamw> ack
19:37:39 <tflink> #agreed 868558 - AcceptedBlocker - Violates the following F18 final release criterion for mirror lists: "The installer must be able to use all supported local and remote package source options"
19:37:50 <tflink> do we still have enough people to keep going?
19:38:34 <jreznik> as I said - I should go out - bakuse is staring on me, barking etc :)
19:38:55 <zodbot> Ticket notification - f18finalnicetohave: [Bug 882147] reclaim dialog allows removing HDISO source <https://bugzilla.redhat.com/show_bug.cgi?id=882147>
19:39:25 <tflink> let's find out
19:39:28 <tflink> #topic (876223) NFSISO installation doesn't use internally mounted DVD repo, instead uses Closest Mirror
19:39:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876223
19:39:34 <tflink> #info Proposed Blocker, anaconda, ON_QA
19:40:21 <tflink> I'm still not 100% clear on the whole NFS/NFSISO blocking status
19:40:23 <kparal> this is blocked on the NFS issue
19:40:29 <tflink> does NFSISO block release if NFS works?
19:40:37 <kparal> tflink: for Final, yes
19:40:51 <kparal> " The installer must be able to use all supported local and remote package source options "
19:41:23 <kparal> there is a fix, but I can't test it until NFS in general is fixed
19:41:34 <kparal> (the famous RC1 issue)
19:41:52 <adamw> er, you can test this if you use the right workarounds, no?
19:41:57 <adamw> i'm pretty sure i tested it for beta and it worked.
19:42:53 <kparal> not sure
19:43:10 <kparal> still, +1 blocker per criteria
19:43:52 <tflink> yeah, it sounds like +1 blocker
19:43:57 <pschindl> +1
19:44:05 <kparal> adamw: it's 99% fixed anyway
19:44:15 <adamw> anyway, i'm +1 blocker as described.
19:44:19 <kparal> adamw: yes you are right, pxeboot works and for netinst I can do the workaround
19:44:35 <adamw> if it's fixed, hey, it's fixed, no problem.
19:44:41 <tflink> proposed #agreed 876223 - AcceptedBlocker - Violates the following F18 final release criterion for NFSISO: "The installer must be able to use all supported local and remote package source options"
19:44:46 <kparal> ack
19:45:03 <pschindl> ack
19:46:58 <tflink> #agreed 876223 - AcceptedBlocker - Violates the following F18 final release criterion for NFSISO: "The installer must be able to use all supported local and remote package source options"
19:47:26 <tflink> OK, do we want to keep going or stop for today?
19:47:58 <tflink> there are 2 more bugs on my "to discuss" list, not counting the blockers that have been proposed since friday
19:48:21 <kparal> let's go on
19:48:33 <tflink> #topic (877623) fedup does not seem to verify the update source
19:48:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=877623
19:48:33 <tflink> #info Proposed Blocker, fedup, NEW
19:49:59 <adamw> sorry, /me a bit distracted but still here
19:50:03 <adamw> count me as acking anything i don't nack
19:50:30 <tflink> proposed #agreed adamw to review all blockers by himself
19:50:34 <tflink> ack
19:50:44 <kparal> is there a tldr version?
19:51:01 <tflink> it's more of an RFE that upgrade sources should be signed and verified
19:51:13 <tflink> AFAIK, this is partially being worked on
19:51:22 <kparal> we have a security criterion now, is it related to that?
19:51:37 <tflink> if things go as planned, we should have a gpg signed .treeinfo that fedup can verify
19:51:43 <tflink> which is part of the issue
19:51:49 <kparal> tflink: the non-trusted download affects just kernel pair, or packages as well?
19:52:20 <tflink> not 100% clear
19:52:37 <kparal> can't we just download over https?
19:52:49 <tflink> I don't think that would solve the issue
19:52:59 <adamw> tflink: grrr
19:53:07 <kparal> because mirror can be subverted, right
19:53:11 <tflink> yep
19:53:19 <tflink> adamw: you acked it implicitly :)
19:54:00 <tflink> the question is whether we block release for it
19:54:03 <adamw> i'm kinda +1 on this, though i'd prefer if we had a clear plan rather than a mushy 'it should be securererr!'
19:54:10 <kparal> if it is doable, we should wait for it
19:54:49 <kparal> but if it amounts to 1 month slip, I would rather drop it
19:55:02 <tflink> so punt, asking for potential implementation details?
19:55:31 <kparal> I don't have much knowledge in this area
19:55:40 <kparal> so more details and time plans would be nice
19:55:50 <kparal> OTOH I don't trust wwoods' time plans
19:56:21 <adamw> yeah, punt
19:56:25 <tflink> I think it's do-able, but I could be missing something
19:57:13 <tflink> proposed #agreed 877623 - We would like to see more information on whether this is possible and if so, how long it would take to implement before voting on blocker status. Will revisit at a later date.
19:57:38 <tflink> #topic (872088) fedup giving grubby backtrace
19:57:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872088
19:57:38 <tflink> #info Proposed Blocker, fedup, ASSIGNED
19:58:05 <tflink> this still needs triage
19:58:33 <tflink> it (or a variant) still seems to be happening but it's not 100% clear to me why or in what situations
19:58:35 <kparal> isn't old fedup version?
19:58:41 <tflink> the original report, yes
19:58:48 <tflink> I hit it with 0.7.1, though
19:59:02 <tflink> and there have been several similar reports in the last couple days
19:59:20 <tflink> it was marked as proposed final blocker since the first one blocked beta
19:59:27 * tflink would say punt
19:59:56 <kparal> ok
20:00:13 <adamw> so we can clarify what's causing it now? agreed
20:00:36 <tflink> proposed #agreed 872088 - This needs more triage into why and in what situations the TB is occuring before deciding on blocker status. Will revisit later.
20:00:49 <kparal> ack
20:01:21 <tflink> #agreed 872088 - This needs more triage into why and in what situations the TB is occuring before deciding on blocker status. Will revisit later.
20:01:26 <tflink> OK, that's all of the bugs from my initial list of stuff needing discussion. Since we're at 2.5 hours, shall we continue on wednesday?
20:02:50 <tflink> the lack of a response makes me think that might be a good idea
20:02:56 <kparal> yes
20:03:19 <tflink> #topic Open Floor
20:03:47 <tflink> I'll try to keep on top of the blockers for now w/ 'obvious' and 'needs discussion'
20:04:05 <tflink> if anyone has time, please go through the list I sent to test@ and vote in-bug
20:04:10 <adamw> yeah, we should go through and accepted/rejected the ones with sufficient votes
20:04:16 <adamw> thanks for working on that tflink!
20:04:35 <jreznik> thanks guys!
20:04:36 <tflink> I don't think that there are many with +/-3
20:04:49 <tflink> but I can check post-meeting unless someone else wants to do it
20:05:10 * tflink will refrain himself from adding enhancements to the blocker tracking app for this
20:05:13 <tflink> :)
20:05:49 * jreznik voted in a few - mostly nouveau once
20:05:53 <tflink> anything else that needs to be brought up now?
20:06:09 <adamw> can't think of anything
20:06:32 <tflink> #info the next blocker review meeting will be 2012-12-05 @ 17:00 UTC
20:06:34 <tflink> oh, I have one
20:06:46 <tflink> location - do we want to continue doing this in #fedora-qa?
20:06:54 <tflink> I forgot to bring that up in the meeting
20:07:07 * tflink wonders if maybe we should go back to bugzappers
20:07:19 <tflink> since we kind of kill conversation in here during the meeting
20:08:23 <tflink> well, it sounds like everyone died so I'll just set the fuse
20:08:29 <jreznik> tflink: or any #fedora-meeting-X where X>=2?
20:08:38 <tflink> jreznik: I don't think those are logged, though
20:08:46 <tflink> s/logged/have meetbot
20:09:00 * kparal is back
20:09:08 <kparal> we should definitely switch channel
20:09:13 <kparal> we block all other conversations
20:09:19 <tflink> but to where?
20:09:24 <jreznik> tflink: zodbot is there
20:09:36 <kparal> https://fedoraproject.org/en/get-prerelease now links here, so we get more visitors
20:09:48 <tflink> is the population any greater in fedora=meeting-3 than bugzappers?
20:09:54 <tflink> typos aside
20:10:12 <jreznik> probably not - but it could be scheduled on https://fedoraproject.org/wiki/Meeting_channel - so probably more people could join us
20:10:33 <kparal> bugzappers is 33 people, meeting-3 7 people
20:10:34 <jreznik> and still -meeting channel is more "the right way" for having fedora related meetings
20:10:53 <tflink> how many other fedora meetings last 3 hours on a regular basis?
20:11:21 <tflink> at semi-randomly scheduled times
20:11:45 <jreznik> not many but that's why I said whew X>=2 - usually free
20:11:51 <jreznik> but I'm ok with bugzappers too
20:12:00 <jreznik> it really kills any non-related communication
20:12:04 <tflink> how about bugzappers for now?
20:12:10 <tflink> s/now/wednesday
20:12:17 * kparal +1
20:12:32 * jreznik is ok with that and agrees we need different channe...
20:12:39 <tflink> not sure what we'll do for the rest of F18 but this process needs to be revamped for the future
20:13:00 <tflink> revamped/broght out back and shot ... whatever :)
20:13:46 <tflink> #info we will be moving the blocker meetings back to #fedora-bugzappers for now - holding it in #fedora-qa is too disruptive
20:14:01 * tflink sets the fuse for some amount of time (positive or negative)
20:14:15 <tflink> Thanks for coming, everyone
20:14:20 <jreznik> fire!
20:14:22 * tflink will send out minutes shortly
20:14:26 <tflink> #endmeeting