17:25:11 #startmeeting f18final-blocker-review-1.2 17:25:11 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:25:12 #meetingname f18final-blocker-review-1.2 17:25:12 The meeting name has been set to 'f18final-blocker-review-1.2' 17:25:12 #topic Roll Call 17:25:37 I see: [OK] Stopped Software RAID Monitor. Takeover ..... Unmounting file systems. Starts unmounting and stops at "Unmounted /sys/kernel/debug" 17:27:06 whoops, a little early 17:27:07 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 adamw: when i report a bug for 17:31:14 adamw: when i report a bug for upgrading f17 to f18beta, what fedora version do I specify for the bug? :) 17:31:29 mel-: depends if the bug happens during the f17 part of the process or the f18 part 17:31:34 before the reboot, or after? 17:31:42 adamw: you beat me to it :) 17:32:40 OK, let's get this party started with some always exciting boilerplate 17:32:43 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 mel-: probably f18 fedup-dracut 17:33:07 #topic Introduction 17:33:17 Why are we here? 17:33:17 #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 #info We'll be following the process outlined at: 17:33:23 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:33:28 #info The bugs up for review today are available at: 17:33:28 #link http://qa.fedoraproject.org/blockerbugs/current 17:33:34 #info The criteria for release blocking bugs can be found at: 17:33:34 #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 17:33:35 #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria 17:33:35 #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria 17:33:54 #info The current blocker/nth list consists of: 17:33:57 #info 44 Proposed Blockers 17:33:57 #info 10 Accepted Blockers 17:33:58 #info 21 Proposed NTH 17:33:58 #info 3 Accepted NTH 17:34:41 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 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 mel-: if you file a bug, can you post the bz number here? I'm curious to see what went wrong 17:36:10 #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 #link https://bugzilla.redhat.com/show_bug.cgi?id=882147 17:36:15 #info Proposed Blocker, anaconda, NEW 17:37:15 the description should be inst.repo=hd:vda1:/dvd.iso 17:37:20 * kparal just noticed the typo 17:37:45 basically I tried to remove the partition I wanted to install from 17:37:46 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 tflink: of course 17:38:16 * pschindl was waiting on the wrong channel 17:38:35 but it could also be argued that trying to delete the source disk is too invalid to block over 17:38:57 i'm a bit borderline on blocker here, yeah 17:39:02 i could see us waiving this in a go/no-go for sure 17:39:05 me to +1 nth - blocker 17:39:18 I wonder what if I tried to resize it? 17:39:24 on go/no-go it would be definitely waived... 17:39:34 but it's definitely +1 nth 17:39:35 kparal: damnit, stop breaking stuff. :) 17:39:35 kparal: that sounds like an invitation for trouble :) 17:39:45 yeah, i'd be +1 nth, though we're kinda early to be worrying about nth. 17:40:01 sounds like we're mostly -1 blocker, +1 nth 17:40:06 isn't freeze in 1 week? 17:40:10 I'm OK with -1 blocker 17:40:21 tflink: freeze is 18th 17:40:30 it would deserve +1 nth I think 17:40:54 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 bit off topic for this meeting anyway, i didn't say we shouldn't vote nth :0 17:41:18 so -1/+1? 17:41:25 adamw: yes 17:41:28 yep 17:41:31 yup 17:41:56 let's talk about the schedule after the meeting :) 17:42:00 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 ack 17:42:11 ack 17:42:13 ack 17:42:17 ack 17:42:18 #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 #topic (545148) livecd boot from iscsi storage 17:42:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=545148 17:42:27 #info Proposed Blocker, dracut, NEW 17:42:58 this is another one which seems to be a blocker, technically 17:43:09 assuming that iSCSI is a valid remote source 17:43:16 but I'm probably -1 blocker on this 17:43:41 and seems it had never worked before... -1 blocker 17:43:43 it concerns just live? 17:43:54 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 it sounds like a dracut issue with mounting iSCSI on boot 17:44:29 Viking-Ice: I think that's been covered elsewhere and I also don't think that release criterion is related 17:44:29 for consistency 17:44:39 jreznik: im not happy with it because it gives us 3 days to do the release and fix all blockers 17:44:39 how is this 'technically a blocker'? 17:44:41 it is iSCSI, yes. but this isn't installing to iSCSI as I'm reading it 17:44:44 I see this as a very uncommon use case 17:44:46 adamw: remote source 17:44:56 precise criterion? 17:45:16 "The installer must be able to use all supported local and remote package source options" 17:45:24 remote *package source options*. 17:45:37 sticking the live image on an iSCSI device and booting from it is not a 'supported remote package source option'. 17:45:55 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 -1 blocker, clearly. 17:45:57 tflink, i'm thinking of consistency here if we wont support iscsi in anaconda why should we do it elsewhere 17:46:12 Viking-Ice: this bug has nothing to do with anaconda, IIRC 17:46:21 s/IIRC/AFAIK 17:46:25 tflink, I know 17:46:39 then I'm missing something 17:46:48 I was just trying to explain why we should punt it 17:47:07 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 tflink: https://bugzilla.redhat.com/show_bug.cgi?id=883072 17:47:19 mel-: thanks 17:47:35 -1 blocker from me as well 17:47:35 welcome 17:48:38 Note: bugzilla.redhat.com outage later today, starting at 17:30EST for 2 hours. 17:48:43 tflink: oh damn, i forgot to specify a severity :) 17:48:45 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 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))') 17:48:58 nirik, what's that in utc ;) 17:49:00 nirik: seriously? Did I miss the announcement? 17:49:06 oh, EST, not UTC 17:49:22 Viking-Ice: let me see... 22:30 I think... 17:50:02 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 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 ack 17:50:48 ack 17:50:49 ack 17:50:52 ack 17:50:54 ack 17:51:04 ack 17:51:37 #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 #topic (874553) rd.debug boot option doesn't log to /run/initramfs/init.log 17:51:46 #link https://bugzilla.redhat.com/show_bug.cgi?id=874553 17:51:46 #info Proposed Blocker, dracut, ASSIGNED 17:53:00 why is this blocker? 17:53:02 so, this one is probably not a blocker unless we want to fudge a bit 17:53:09 it hinders debugging of dracut 17:53:16 -1 blocker 17:53:21 -1 blocker 17:53:22 because of LiveCDs? 17:53:23 -1 blocker 17:53:23 i don't see any justification in the bug 17:53:37 yeah, I probably should have added a comment 17:53:42 probably fails the 'if this was go/no-go...' smell test 17:53:45 provisional -1 17:53:59 -1/+1 17:53:59 * adamw willing to give tflink a chance :) 17:54:15 debugging dracut without init.log is a huge PITA 17:54:34 is not the output in the journal ? 17:54:50 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 seems like it could be fixed with an update for most cases, as kparal points out. 17:55:45 yup 17:55:55 except for LiveCDs 17:55:59 sure, as long as the installer doesn't have problems booting 17:56:36 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 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 stray slash at the end 17:56:49 ack 17:56:50 ack 17:56:51 ack 17:56:53 ack 17:56:56 ack 17:56:58 #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 ack 17:57:08 #topic (873817) inkscape packaging bugs prevent install 17:57:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=873817 17:57:08 #info Proposed Blocker, inkscape, ASSIGNED 17:57:41 this is another one that doesn't seem clear cut 17:58:06 while inkscape is on the DVD, I don't believe it's part of any of the default DE package groups 17:58:14 I am testing F18 install process. How do I set up raid? I have got to the Installation Manual Partitioning page. 17:58:22 still, we try to not have packaging problems in the release media 17:58:29 so if a user installed inkscape from the DVD, anaconda would crash 17:58:46 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 i'd argue we hit the spirit of that criterion, though not the letter 17:59:01 should be a blocker 17:59:22 i'd suggest modifying it to add something like 'or any other packaging error causing installation of a package to fail' 17:59:30 and +1 blocker on the basis of that mod 18:00:02 adamw: actually just saying "no packaging errors" would be fine, conflicts and broken dependencies are packaging errors 18:00:18 +1 blocker 18:00:34 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 but we can thrash out the details on-list 18:01:13 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 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 patch 18:01:59 tflink: AcceptedBlocker 18:02:08 i think he was splitting it in two? 18:02:15 aha 18:02:20 adamw: thanks 18:02:26 ack then 18:02:33 kparal: huh? that was just about the proposed criteria change 18:02:39 nvm, I'm slow 18:03:00 other ack/nak/patch? 18:03:45 * kparal kicks pschindl jskladan 18:03:54 ack 18:03:59 ack 18:04:05 that's it! 18:04:07 ack assuming another one is coming 18:04:07 sorry, preocupied by food :) 18:04:08 #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 let's just focus on the bug in question and have the release criteria proposal on -.test 18:05:07 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 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 ack 18:05:51 Ticket notification - f18finalnicetohave: [Bug 874486] progress indicator for mediacheck isn't displayed, so users may think the installer is hung 18:06:04 ack 18:06:06 ack 18:06:06 ack 18:06:33 #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 #topic (873207) No entry in grub2 menu for windows8 in dual boot setup install TC7 18:06:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=873207 18:06:51 #info Proposed Blocker, os-prober, NEW 18:07:35 if I'm understanding this correctly - the issue is that a windows entry isn't automatically added to the grub menu 18:08:05 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 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 tflink: so how do you boot? 18:08:23 +1 blocker 18:08:38 kparal: modify grub in fedora after install 18:08:40 I'd be +1 blocker for Win 7. Win 8 coverage is extremely small now, I can imagine we reject it 18:08:43 like the "good old days" 18:09:05 tflink: then we don't have to have any criteria at all, because everything can be modified 18:09:08 manually 18:09:23 how does this prevent you from dual booting? 18:09:32 I don think it's wize to start chasing down windows version 18:09:36 " install a bootloader which can boot into the Windows installation" is pretty clear 18:09:46 ah, I missed that part 18:10:06 too much bz in one day makes the head spin 18:10:42 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 the bootloader can boot into windows, but I'm splitting hairs here 18:10:50 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 barry_scott: not sure, sorry. oh, RAID will be disallowed for some partitions (/boot and swap, I think) 18:11:37 adamw: If this is documented I'll happily read the docs 18:11:49 kparal: at least Win8 certified does not support BIOS but I hope it's installable on the older ones 18:11:51 RAID works great for /boot we use it all the time 18:11:57 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 yeah, this criterion was really written for BIOS 18:12:16 UEFI isn't required for Win8, but a test of a UEFI install is completely different from a BIOS test 18:12:33 we can't conclude from a UEFI test that a BIOS case is buggy. 18:12:42 right 18:13:00 I wonder whether someone has Win8 to test 18:13:16 not here 18:13:22 not me 18:13:24 rh may have some kind of site license, i guess we could check 18:13:37 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 /me hates laggy internet connections... 18:14:18 well if not a blocker the criteria needs to be adjusted or droppe 18:14:19 d 18:14:20 other thoughts? 18:14:28 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 I'm seeing +2/-2 ATM 18:15:08 I'm only +1 because it's clearly in the criteria 18:15:15 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 in general I'm against having this in the criteria et all ( dualboot with windows ) 18:15:41 mean having this criteria et all 18:16:03 so people that are for it will just have to suck it up and have us block the release ;) 18:16:10 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 I'm +1/-1. I'll ask Spice guys whether they have a win8 license 18:16:19 i love these ambiguous criteria where we can read a single success as a pass. :P 18:16:24 err 18:16:26 -1/+1 18:16:44 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 so punt and ask someone with win 8 to give us more data? 18:17:10 btw from linked bug reports it seems like patches does exist 18:17:20 I'd decide based on UEFI and ask to re-propose if someone finds it broken also with BIOS 18:17:42 ok -3/+1 18:17:52 kparal: well it sounds reasonable 18:18:11 if you hit it with BIOS, you're screwed up, with UEFI, you're not (probably) 18:18:20 Is my next step to raise a bug on the no RAID in installer? 18:18:25 jreznik: eh? no. you can't hit this bug with BIOS. it is entirely UEFI specific. 18:18:30 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 barry_scott: i'd ask in #anaconda what's going on in your case 18:18:49 adamw: just following what kparal said... 18:18:50 still, it sounds like we're solidly -1 on this, for whatever personal reasons everyone has. :) 18:18:52 any other votes? 18:18:53 adamw: thanks will do 18:19:04 we're still -3/+1 unless I missed a vote somewhere 18:19:04 jreznik: well if it's broken with BIOS that would be a different bug, not this one. 18:19:23 ok, so -1 blocker 18:19:37 -4/+1 18:20:00 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 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 ack 18:21:13 ack 18:21:13 or maybe remove that BIOS part? 18:21:16 ack 18:21:26 as it will be different bug as adamw pointed out 18:21:31 ack 18:21:54 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 #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 #topic (867770) anaconda GUI becomes unresponsive 18:22:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=867770 18:22:19 #info Proposed Blocker, anaconda, MODIFIED 18:22:40 +1 blocker 18:23:35 i'm pretty close to +1 blocker on this, yeah. it's pretty annoying and confusing. 18:23:39 I'm +1 blocker in spirit but I'm not sure about the criterion to use 18:23:53 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 oh, wait, this is a slightly different one 18:24:14 sorry 18:24:25 * satellit are they waiting for resolving software before trying this? 18:24:57 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 this should be marked in ON_QA i think, since 18.32 is built 18:25:30 oh, 18.34 even. 18:25:45 yeah, .33 was skipped due to some build problems - I didn't ask for specifics 18:27:03 +1 blocker 18:27:03 i guess i'd say +1, treat it as a crasher. 18:27:22 criterion? 18:27:32 The installer must be able to complete an installation using all supported interfaces 18:27:37 whatever we usually use for install crashers? 18:27:38 we, 18:27:39 pick one :) 18:27:42 yeah, a conditional violation of something like that 18:27:55 on the basis that enough people have seen it 18:27:56 mean well any installer must complete ( if it freezes it violates that ; ) ) 18:28:01 right. 18:28:04 "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 yup sounds appropriate 18:28:29 Ticket notification - commonbugsrss: [Bug 873207] No entry in grub2 menu for windows8 in dual boot setup install TC7 18:28:56 good enough 18:29:24 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 is that too long? 18:29:51 it's fine ack 18:30:14 ack 18:30:17 ack 18:30:36 ack 18:30:54 ack 18:31:32 #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 #topic (879030) pungi strips langpacks metadata from comps, breaks langpacks installation for DVD 18:31:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=879030 18:31:51 #info Proposed Blocker, yum, NEW 18:32:19 +1 blocker - comment #2, and web browsing is in the critpath 18:32:23 with this bug, you don't get the firefox translations 18:32:40 so, criterion is violated. 18:32:50 this could be fixed via update ? 18:32:51 +1 18:32:57 no 18:33:08 you can install the translations manually 18:33:13 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 +1 18:33:34 so actually firefox update could download the translations 18:33:46 the same for libreoffice etc 18:34:02 eh? we just said it doesn't do that 18:34:15 well, update vs reinstall 18:34:18 both work, right? 18:34:23 i don't *think* so 18:34:31 aiui 'yum update firefox' won't add the langpack, but 'yum reinstall firefox' will 18:34:37 ah 18:34:40 we should check though i guess - if an update fixes it, that's less of a problem 18:35:00 still the user would get untranslated apps for quite some time 18:35:11 hunspell and similar might not be updated frequently 18:35:17 well, we could just ship an update for every package with a langpack to force the reinstall, in theory 18:35:32 adamw: but if someone installs a week later... 18:35:33 should we make it acceptedblocker assuming 'yum update' doesn't add the translations, punt if it does? 18:35:37 i can check that async 18:35:48 kparal: net install works fine, bug affects dvd only. 18:36:04 not sure what happens if you do DVD install with the update repo enabled :) 18:36:17 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 I think it should be a blocker in both cases 18:36:29 * tflink will edit 18:36:34 s/will/can 18:36:42 i'll ack that, and i can re-propose the bug if it turns out to be wrong 18:36:42 ack 18:36:45 ack 18:36:47 i'm testing in the background 18:36:48 ack 18:36:48 ack 18:37:03 ack 18:38:34 #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 #topic (860525) dracut-pre-pivot[272]: mount: wrong fs type, bad option, bad superblock on /var/lib/nfs/rpc_pipefs, 18:38:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=860525 18:38:50 #info Proposed Blocker, dracut, NEW 18:39:30 according to c#11, this could affect NFS installs 18:40:17 tflink: but it seems to affect installed system 18:40:20 * kparal is confused 18:40:47 so am I, I probably should have left this off the list 18:40:50 * adamw reads 18:41:15 looks like we need more data 18:41:21 "This would prevent possible NFS install errors." 18:41:27 hey, now I'm confused too! 18:41:34 install and install errors are two different thing ;) 18:41:38 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 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 punt and wait for more info 18:43:15 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 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 ack 18:43:44 ack 18:43:46 ack 18:43:51 #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 ack 18:44:02 #topic (861219) Switching to discret GPU render system unusable 18:44:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=861219 18:44:02 #info Proposed Blocker, xorg-x11-drv-nouveau, NEW 18:44:36 this is pretty clear, just didn't go out on the list due to missing info 18:44:39 -1 blocker from me 18:44:45 -1 blocker 18:44:52 -1 blocker, see my comment in bug 18:45:19 -1, yeah, switcheroo is all still experimental and unsupported. 18:45:28 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 ack 18:45:32 ack 18:45:35 ack 18:45:38 #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 #topic (873144) pressing Esc kills plymouth screen 18:45:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=873144 18:45:48 #info Proposed Blocker, plymouth, NEW 18:46:42 bah, I'm trying to do too many things @ the same time again 18:46:53 i'm not sure that *this* is quite the right bug to block on 18:46:55 ? this is intended behaviour afaik 18:47:05 either way, this might be fixed (I haven't tried in new plymouth) but I'm not sure 18:47:10 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 yeah 18:47:17 but blocking on 'esc makes plymouth go away' seems wrong. 18:47:23 yup 18:47:25 this bug isn't well named 18:47:32 tflink: I don't understand why this is +1 blocker from you, but the lack of progress bar is -1 18:47:58 I guess I just see log info as more important 18:48:07 but in reality, I'd be OK with one or the other 18:48:27 "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 that applies for missing progress bar as well 18:49:11 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 but right now it's not clearly that 18:49:19 progress bar ( or some other indication upgrading is (still) taking place ) text/gui mode is necessary for final 18:49:26 kparal: like I said, "in reality id be OK with one or the other" 18:49:56 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 I wonder if using 883075 as the blocker would be best 18:50:15 even though I closed it as a dupe of this 18:50:23 should we just nack this one and create a new one that explicitly states what we are after? 18:50:35 (source of the 'doing too many things at the same time comment') 18:50:52 Viking-Ice: either that, or punt 18:50:57 either way, give tflink a bit of time to clean it up nice 18:51:20 I think we should decide whether we want progress bar to block, and treat this one the same 18:51:20 are we leaning towards reject or punt? 18:51:42 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 I think we all are on the same page we ant progress bar 18:51:49 mean want 18:51:54 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 adamw: we have that one 18:52:11 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 adamw: https://bugzilla.redhat.com/show_bug.cgi?id=879295 18:52:25 adamw: you both voted -1 in it 18:52:26 what about using 883075? 18:52:44 or do we want to file a new bug? 18:53:01 * kparal is confused. what's wrong with 879295? 18:53:02 i think i misread that one 18:53:20 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 it seems too confused to sort it out here 18:53:27 sure 18:53:31 we already wasted a lot of time 18:53:47 hm 883075 looks like a good candidate 18:54:01 to accept and file rest as dupes of that one 18:54:11 #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 Viking-Ice: they aren't dupes, though 18:54:24 there are two different issues: 1) missing progress bar 2) plymouth killed on key press 18:54:27 there are just multiple issues affecting fedup status during upgrade 18:54:50 1) is 879295 and 2) is 873144 18:55:01 it's really simple 18:55:04 we should just have a blinking text that says still upgrading ;) 18:55:39 #action tflink to clean up fedup upgrade status bugs and propose one as a blocker for F18 final 18:56:21 #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 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 ack 18:57:10 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 ack 18:57:17 ack 18:57:26 #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 #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 #link https://bugzilla.redhat.com/show_bug.cgi?id=881670 18:57:45 tflink: btw, i don't know if i pressed esc. I think not. 18:57:45 #info Proposed Blocker, systemd, NEW 18:57:54 +1 blocker 18:58:09 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 tflink: that's fine! just trying to add info. 18:58:58 "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 adamw: I think the word "killed" caused the misunderstanding. nevermind now 18:59:11 tflink: i think me pressing keys (like e.g. virtual console switching) was a reaction to not seeing any messages. 18:59:23 new bug people ;) 18:59:36 it is and it isn't 18:59:47 btw. is this one the three hours long or one hour long meeting - my dog really wants to go out :) 19:00:03 this could be a contributing factor to the issues that mel- hit 19:00:30 are we talking about 881670 now? 19:00:44 yeah, I just read your comments and realize that I misunderstood 19:00:46 I am 19:01:06 we moved to that bug? 19:01:23 so long as 861123 is -1, this is -1. 19:01:34 jreznik: i think we're on 2-3 hours today. 19:01:40 adamw: no 19:01:59 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 in 881670 fstab was not adjusted and it can't be fixed with an update 19:02:16 well, that's a point. but i was -1 on that anyway. 19:02:29 adamw: ok, I'll be back in half hour... bakuse is getting crazy... 19:02:30 we've never guaranteed to clean things up super nicely on upgrade. 19:03:05 adamw: I don't see a technical problem here. you just say we don't care 19:03:05 jreznik, 2 hours is fine for me I'm heading home from work after this one 19:03:20 ( 19:00 ) here ... 19:04:11 I'm still slightly confused - is the bug that all upgrades w/ encrypted disks will fail post-upgrade? 19:04:18 kparal: we don't decide blockers based on technical issues, but quality expectations. 19:04:19 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 I'm leaning towards +1 blocker here this does affect every upgrade with encrypted partition right? 19:04:31 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 tflink: they will fail on every boot if you don't type your password in time (1-2 minutes) 19:05:02 (after upgrade) 19:05:03 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 this is fedup hook we talk about 19:05:31 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 kparal: i know. 19:05:37 fedup-dracut to be precise 19:05:44 but still, is there anything saying we can't update the hooks? 19:06:05 Lennart says in bug 861123 it can't be done 19:06:06 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 in fedup? 19:06:21 otherwise they would do it as part of systemd update 19:06:32 that's why he requested anaconda folks to do it 19:06:35 adamw, for the general case of your not fast enough to type your password on I'm -1 blocker 19:06:44 -1 nth 19:07:23 since in that usecase you are powering up your computer and are next to it 19:07:38 at it I mean 19:07:48 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 could be sensible message shown in dracut shell? 19:08:06 dunno. 19:08:11 Viking-Ice: if you hit Reboot and it takes a lot of time, you go for a sandwich 19:08:23 if this was the last blocker left in go/no-go, would we slip release for this? 19:08:23 steak I go for a steak! ;) 19:08:31 tflink: yes 19:08:35 tflink, yes 19:08:47 Viking-Ice: i thought you were -1 blocker 19:08:57 I'm also confused about that 19:08:59 tflink: I'd say no... for go/no-go 19:09:18 but yeah, at least a sensible message makes sense 19:09:48 tflink, +1 for the upgrade case ( 881670 ) -1 ( 861123 none upgrade ) 19:10:08 we're now talking about 881670 19:10:24 so +1 from Viking-Ice 19:10:57 I can't imagine more severe regression then breaking boot 19:11:11 *than 19:11:26 sure but unless I'm misunderstanding something, this isn't really breaking boot 19:11:35 comment #1 says the criteria 19:11:40 a PITA and something that probably shouldn't be done, sure 19:11:53 * jreznik agrees with tflink 19:12:04 yes, how is this breaking boot? 19:12:09 can you not just reboot and try again? 19:12:24 I really don't understand how this is different from the install case 19:12:25 adamw: so how do you reboot if you don't know magic commands? hard reboot, the only option 19:12:27 is that safe? 19:12:42 true. 19:13:41 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 and it can't be fixed with an update. sorry, but this one is an obvious blocker for me 19:13:45 maybe we need more perspectives? 19:14:26 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 in the case of upgrade-ness it's an clear blocker to me 19:15:05 I'm thinking punt 19:15:23 I'm pretty sure that reboot would be safe during upgrade for encrypted / 19:15:31 but I'm not so sure about encrypted /home only 19:15:47 tflink: good one 19:15:54 the / is already mounted rw 19:15:58 isn't it 19:16:15 the upgrade can't start if / isn't mounted 19:16:28 tflink: this is not about the upgrade process 19:16:37 this is about every boot after upgrade is finished 19:17:08 every computer start up forever, since the time you upgraded 19:17:14 fair enough 19:17:19 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 ? 19:17:20 ok, punt today and ask for more opinions + possibilities? 19:17:43 adamw: I'm afraid I can explain it properly, because you still don't get it 19:17:44 :/ 19:18:06 this has to be fixed in fedup, because if it is not, it will affect every computer boot afterwards 19:18:13 I think I understand the post-upgrade issue. I just disagree that it's a blocker 19:18:13 fstab has to be modified during upgrade 19:18:17 kparal: i know that. 19:18:26 Mexican standoff 19:18:36 2 +1 vs 2 -1 19:18:37 i am referring to " 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 " 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 " Viking-Ice: if you hit Reboot and it takes a lot of time, you go for a sandwich" 19:18:57 those are two different situations 19:19:02 adamw: that the consequence, because fedup will auto-reboot, and it will time out afterwards 19:19:05 one is during upgrade, the other is after 19:19:08 you keep citing the case where you do an upgrade, because in that case, you hit the button and walk away. 19:19:11 tflink: *I KNOW* 19:19:25 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 this is the same issue 19:19:34 that argument does not apply post-upgrade, because you aren't likely to do that. 19:19:39 unless, of course, you're doing an offline update... 19:20:04 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 why not? 19:20:18 because why would they? 19:20:27 and even if they did, they can reboot 19:20:28 install updates, hit Reboot, turn around and talk to someone 19:20:31 for steak I would for a steak ;) 19:20:32 in another room perhaps 19:20:34 you provided a plausible scenario where someone would do so: an OS upgrade via fedup. fine. I accept that. 19:20:44 but that scenario isn't a post-upgrade scenario. 19:21:07 it's the same problem 19:21:13 it is the same technical bug. yes. 19:21:26 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 anyhow, i think we have all the issues clearly enough now... 19:21:45 yes, and all of that is caused by 881670 19:21:54 i know. 19:22:06 I think we should let it rest :) 19:22:10 for a while 19:22:13 yeah 19:22:35 #propose punt 19:22:50 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 ack 19:23:03 * jreznik already said that 6 minutes ago :) 19:23:04 ack with bacon 19:23:17 ack with steak (/me is on diet now...) 19:23:23 ack 19:23:45 ack 19:23:56 #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 jreznik, I should go on a diet but fucking I only live once anyway ;) 19:24:11 ack 19:24:13 #topic (868558) anaconda needs to tell yum what's a URL and what's a mirrorlist 19:24:16 #link https://bugzilla.redhat.com/show_bug.cgi?id=868558 19:24:18 #info Proposed Blocker, anaconda, ASSIGNED 19:24:37 well here I bid farewell and leave you to it 19:24:41 later 19:24:55 Viking-Ice: see you! 19:25:01 cya viking 19:25:48 kparal: so it's now only about "The checkbox description still needs adjustment"? 19:26:00 I don't know 19:26:14 tflink: adamw: were your votes about GUI or about the issue as a whole? 19:26:37 I think I got confused a bit in there 19:27:06 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 the issue as a whole 19:27:29 the failure to be able to use mirrorlists at all is obvious +1 19:27:35 the 'current' state is a bit funny 19:27:41 tflink: so it the checkbox labels stays incorrect (mirror instead of mirrorlist), do we still want to block on that? 19:27:44 *if 19:27:50 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 unless they remember it from oldui, and i didn't 19:28:15 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 so though i said "UI niggles aren't blocker"...this one might be 19:29:13 yeah, at least +1 nth on the UI 19:29:16 it's like a self-destruct button with a label saying 'PRESS HERE TO PREVENT SELF-DESTRUCT' 19:29:23 not helpful :) 19:29:37 +1 nth for sure 19:30:08 definite nth, i'm close to blocker even just for the label. it'd really suck to have that in there. 19:30:11 but is the UI issue a different bug? 19:30:23 it's covered in the same bug report 19:30:55 that's arguable 19:31:14 you can specify a mirror list 19:31:25 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 I'm not saying that it isn't a blocker, just wondering if it needs to be a new bug 19:32:11 ideally yeah it should be. i'll split it out. 19:32:19 shall we just for now say that this bug as written is clearly +1 blocker? 19:32:21 since it is. 19:32:26 yes 19:32:32 i can separate out the UI issue and propose it separately if it doesn't get a quickfix. 19:32:38 adamw: but move it to VERIFIED then 19:32:46 right, i'll do the cleanup. 19:32:57 (868558) 19:33:07 ok 19:33:11 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 ack 19:35:20 other ack/nak/patch? 19:35:55 pschindl: say ack 19:36:47 ack 19:37:39 #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 do we still have enough people to keep going? 19:38:34 as I said - I should go out - bakuse is staring on me, barking etc :) 19:38:55 Ticket notification - f18finalnicetohave: [Bug 882147] reclaim dialog allows removing HDISO source 19:39:25 let's find out 19:39:28 #topic (876223) NFSISO installation doesn't use internally mounted DVD repo, instead uses Closest Mirror 19:39:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=876223 19:39:34 #info Proposed Blocker, anaconda, ON_QA 19:40:21 I'm still not 100% clear on the whole NFS/NFSISO blocking status 19:40:23 this is blocked on the NFS issue 19:40:29 does NFSISO block release if NFS works? 19:40:37 tflink: for Final, yes 19:40:51 " The installer must be able to use all supported local and remote package source options " 19:41:23 there is a fix, but I can't test it until NFS in general is fixed 19:41:34 (the famous RC1 issue) 19:41:52 er, you can test this if you use the right workarounds, no? 19:41:57 i'm pretty sure i tested it for beta and it worked. 19:42:53 not sure 19:43:10 still, +1 blocker per criteria 19:43:52 yeah, it sounds like +1 blocker 19:43:57 +1 19:44:05 adamw: it's 99% fixed anyway 19:44:15 anyway, i'm +1 blocker as described. 19:44:19 adamw: yes you are right, pxeboot works and for netinst I can do the workaround 19:44:35 if it's fixed, hey, it's fixed, no problem. 19:44:41 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 ack 19:45:03 ack 19:46:58 #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 OK, do we want to keep going or stop for today? 19:47:58 there are 2 more bugs on my "to discuss" list, not counting the blockers that have been proposed since friday 19:48:21 let's go on 19:48:33 #topic (877623) fedup does not seem to verify the update source 19:48:33 #link https://bugzilla.redhat.com/show_bug.cgi?id=877623 19:48:33 #info Proposed Blocker, fedup, NEW 19:49:59 sorry, /me a bit distracted but still here 19:50:03 count me as acking anything i don't nack 19:50:30 proposed #agreed adamw to review all blockers by himself 19:50:34 ack 19:50:44 is there a tldr version? 19:51:01 it's more of an RFE that upgrade sources should be signed and verified 19:51:13 AFAIK, this is partially being worked on 19:51:22 we have a security criterion now, is it related to that? 19:51:37 if things go as planned, we should have a gpg signed .treeinfo that fedup can verify 19:51:43 which is part of the issue 19:51:49 tflink: the non-trusted download affects just kernel pair, or packages as well? 19:52:20 not 100% clear 19:52:37 can't we just download over https? 19:52:49 I don't think that would solve the issue 19:52:59 tflink: grrr 19:53:07 because mirror can be subverted, right 19:53:11 yep 19:53:19 adamw: you acked it implicitly :) 19:54:00 the question is whether we block release for it 19:54:03 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 if it is doable, we should wait for it 19:54:49 but if it amounts to 1 month slip, I would rather drop it 19:55:02 so punt, asking for potential implementation details? 19:55:31 I don't have much knowledge in this area 19:55:40 so more details and time plans would be nice 19:55:50 OTOH I don't trust wwoods' time plans 19:56:21 yeah, punt 19:56:25 I think it's do-able, but I could be missing something 19:57:13 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 #topic (872088) fedup giving grubby backtrace 19:57:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=872088 19:57:38 #info Proposed Blocker, fedup, ASSIGNED 19:58:05 this still needs triage 19:58:33 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 isn't old fedup version? 19:58:41 the original report, yes 19:58:48 I hit it with 0.7.1, though 19:59:02 and there have been several similar reports in the last couple days 19:59:20 it was marked as proposed final blocker since the first one blocked beta 19:59:27 * tflink would say punt 19:59:56 ok 20:00:13 so we can clarify what's causing it now? agreed 20:00:36 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 ack 20:01:21 #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 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 the lack of a response makes me think that might be a good idea 20:02:56 yes 20:03:19 #topic Open Floor 20:03:47 I'll try to keep on top of the blockers for now w/ 'obvious' and 'needs discussion' 20:04:05 if anyone has time, please go through the list I sent to test@ and vote in-bug 20:04:10 yeah, we should go through and accepted/rejected the ones with sufficient votes 20:04:16 thanks for working on that tflink! 20:04:35 thanks guys! 20:04:36 I don't think that there are many with +/-3 20:04:49 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 :) 20:05:49 * jreznik voted in a few - mostly nouveau once 20:05:53 anything else that needs to be brought up now? 20:06:09 can't think of anything 20:06:32 #info the next blocker review meeting will be 2012-12-05 @ 17:00 UTC 20:06:34 oh, I have one 20:06:46 location - do we want to continue doing this in #fedora-qa? 20:06:54 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 since we kind of kill conversation in here during the meeting 20:08:23 well, it sounds like everyone died so I'll just set the fuse 20:08:29 tflink: or any #fedora-meeting-X where X>=2? 20:08:38 jreznik: I don't think those are logged, though 20:08:46 s/logged/have meetbot 20:09:00 * kparal is back 20:09:08 we should definitely switch channel 20:09:13 we block all other conversations 20:09:19 but to where? 20:09:24 tflink: zodbot is there 20:09:36 https://fedoraproject.org/en/get-prerelease now links here, so we get more visitors 20:09:48 is the population any greater in fedora=meeting-3 than bugzappers? 20:09:54 typos aside 20:10:12 probably not - but it could be scheduled on https://fedoraproject.org/wiki/Meeting_channel - so probably more people could join us 20:10:33 bugzappers is 33 people, meeting-3 7 people 20:10:34 and still -meeting channel is more "the right way" for having fedora related meetings 20:10:53 how many other fedora meetings last 3 hours on a regular basis? 20:11:21 at semi-randomly scheduled times 20:11:45 not many but that's why I said whew X>=2 - usually free 20:11:51 but I'm ok with bugzappers too 20:12:00 it really kills any non-related communication 20:12:04 how about bugzappers for now? 20:12:10 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 not sure what we'll do for the rest of F18 but this process needs to be revamped for the future 20:13:00 revamped/broght out back and shot ... whatever :) 20:13:46 #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 Thanks for coming, everyone 20:14:20 fire! 20:14:22 * tflink will send out minutes shortly 20:14:26 #endmeeting