17:01:09 #startmeeting Fedora 17 Final Go NoGo Meeting Round 2 17:01:09 Meeting started Thu May 24 17:01:09 2012 UTC. The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:40 * satellit_Tris55R listening 17:03:26 dude. 17:03:45 * nirik waves 17:03:54 My irc host just died. Rather inconvenient as I hadn't chaired anyone. 17:04:21 me hrms 17:04:22 rbergero: I think you can get an admin to add a chair 17:04:29 I can do it. 17:04:32 nirik: thank you 17:04:47 sorry for the idiocy / inconvenience, just wanted to make sure we started this meeting off awesomely 17:04:56 rbergero: ;) 17:05:09 i think it will be gogo today 17:05:14 addchair #fedora-meeting-1 freenode rbergero 17:05:20 .addchair #fedora-meeting-1 freenode rbergero 17:05:20 nirik: Chair added: rbergero on (#fedora-meeting-1, freenode). 17:05:23 woot 17:05:28 #chair adamw dgilmore tflink nirik 17:05:28 Current chairs: adamw dgilmore nirik rbergero rbergeron tflink 17:05:38 #meetingname Fedora 17 Final Go NoGo Meeting Round 2 17:05:38 The meeting name has been set to 'fedora_17_final_go_nogo_meeting_round_2' 17:05:46 #topic Why are we here 17:05:51 Okay, going to sing the usual song here: 17:06:54 #info The purpose of this meeting is to determine the "shippiness" of the final release of F17 (RC4, to be specific). All blocker bugs must be resolved, the test matrices need to be completed, we need to meet final release criteria, QA needs to be on board. :) 17:07:01 Any questions? 17:07:18 We'll hit these areas one at a time, more or less. 17:07:23 #topic Blocker Bugs 17:07:27 tflink: greetings sir 17:08:03 ATM, we have 2 proposed blockers to deal with 17:08:13 the 1 accepted blocker is VERIFIED 17:08:21 #link http://fedoraproject.org/wiki/Current_Release_Blockers 17:08:27 which I just updated before the meeting 17:08:31 tflink: i see that 17:09:10 I think that both of the proposed blockers are going to be rejected but let's go through them to make it more-or-less-official 17:09:12 * dgilmore sees no proposed blockers there 17:09:13 so https://admin.fedoraproject.org/updates/anaconda-17.29-1.fc17 needs to get pushed stable 17:09:14 want to walk us through them? :) 17:09:20 dgilmore: refresh 17:09:32 #topic (824191) nfsiso install hangs during reboot 17:09:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=824191 17:09:32 #info Proposed Blocker, NEW 17:09:32 dgilmore: that happens to me all the time :) 17:09:59 this one is a little interesting 17:10:35 I'd like to take the time to thank Bugzilla for being awesome since the upgrade, it has made life fantastically epic for QA guys. :) 17:10:52 the votes in the bug seem to be mostly -1 blocker 17:10:56 eh, we have searches. 17:11:09 adamw: we do now, they didn't work for a couple days there 17:11:15 :) 17:11:18 you can tell how hard i'm working! 17:11:36 so when we hit this bug i started thinking of jlaska's 'point of diminishing returns' 17:11:52 anyways, the issue at hand is that installing with nfs as the sole source causes the target to not reboot nicely after install 17:12:03 im -1 blocker. not ideal. but reset teh system and its ok 17:12:12 which isn't a huge issue if you're installing by hand but if you're attempting to automate, it can be a bigger issue 17:12:16 as long as we keep holding the release we'll keep finding bugs that look a bit bad, and without any context it's easy to keep taking them as blockers, but...this really isn't _so_ terrible, in the end. we're fedora, not rhel. you can't really expect your 2000 machine automated deployment to run without a hitch. 17:12:36 adamw: right 17:12:39 * kparal takes notes 17:12:45 the criteria don't specify that reboot has to work, specifically. just that the install has to work (which it does) and the installed system has to boot (which it does). 17:13:14 adamw: yup 17:13:17 adamw: right 17:14:02 and i believe the updates.img mechanism in 17 is substantially improved from before - an updates.img can now touch just about all of the installer environment - so i think the chances of being able to provide an updates.img for this bug are pretty good...dunno if we have anyone from anaconda around to confirm that. 17:14:08 I think we're splitting hairs a bit here, but honestly - if you have a huge automated install system and this is an issue, you could switch to http repos, use an updates.img or spin up a custom initrd for your own use 17:14:34 yeah, i just don't see this completely killing anyone, no matter how hard i try. 17:15:32 so...shall we vote? 17:15:38 tflink: right, plenty of ways to not hit it 17:15:46 adamw: -1 blocker -1 nth 17:16:07 * nirik is also -1, -1 17:16:07 #agreed 17:16:18 also, kickstart installations over nfs (without repo= boot option) seem to work fine 17:16:21 -1/-1 17:16:22 adamw: rvykydal said the same, updates.img can touch the whole system 17:16:38 kparal: i think the only bit we can't hit with an updates.img is dracut, and this doesn't look likely to be there 17:17:00 proposed #agreed - 824191 - RejectedBlocker - While this is a bug, it doesn't directly violate any of the Fedora 17 release criteria (the isntall completes, the installed system works). Given that it should only affect a minority of users and could be fixed with an updates.img - it doesn't need to block release. 17:17:21 ack/nak/patch? 17:17:22 ack 17:17:26 ack 17:17:27 s/isntall/install/ ;) 17:17:31 ack 17:17:40 ack 17:17:45 proposed #agreed - 824191 - RejectedBlocker - While this is a bug, it doesn't directly violate any of the Fedora 17 release criteria (the install completes, the installed system works). Given that it should only affect a minority of users and could be fixed with an updates.img - it doesn't need to block release. 17:18:04 ack 17:18:04 red_alert: good catch, I've been doing that for the last week or 2. not sure why 17:18:12 #agreed - 824191 - RejectedBlocker - While this is a bug, it doesn't directly violate any of the Fedora 17 release criteria (the install completes, the installed system works). Given that it should only affect a minority of users and could be fixed with an updates.img - it doesn't need to block release. 17:18:24 still ack =) 17:18:29 #topic (824641) kernel 3.3 crashes with blk_dump_rq_flags+ when using a file:/// backend instead of phy:// backend 17:18:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=824641 17:18:35 #info Proposed Blocker, NEW 17:18:46 lol 17:18:46 ack 17:19:22 This is an issue with xen but it's only with F17 as Dom0 (virt host), not DomU (guest) and thus, doesn't hit the xen release criterion 17:19:31 as long as we're sure of that, i'm okay 17:19:37 though the latest comment on the bug seems more equivocal 17:19:41 not sure how that relates to your test 17:20:10 adamw: which comment? 17:20:15 can I chime in? 17:20:21 sure, go for it 17:20:27 ec2 works ok 17:20:27 btw, this is konrad. 17:20:33 ;) 17:20:49 hey backwards konrad 17:20:57 for anyone playing along at home, konrad is our pet xen expert =) 17:21:19 I've no clue whether domU (f17) is using something new that f16 is not using. Meaning that the issue could be in blkfront (so domU) or in dom0. 17:21:52 or in other words. this bug has been in there for eons and until now hadn't been exposed b/c whatever 'fdisk' is doing has changed between f16 and f17. 17:21:53 darnok: if it was a problem in domU, wouldn't my test w/ F16 Dom0 have failed? 17:21:53 darnok: how about tflink's test where he found it worked okay if he used an F16 dom0 with an old kernel? 17:22:14 xen is almost teh same between f16 and f17 17:22:56 tflink, oh. I missed that. It could be. The thing is that there is another piece that is used when you use 'file'. That is the loop driver. 17:23:32 tflink, And also on the whole how the block system has changed between f16 and f17. 17:23:44 tflink, But I am leaning towards it being a dom0 issue. 17:24:09 tflink, And there is a workaround - just use 'phy' (so LVM or raw partition). 17:24:13 well C #4 says that criterion only covers usage as a DomU. 17:24:22 darnok: is there anything that we could do in the next hour or so to confirm that it isn't a domU issue? 17:24:31 akshayvyas: right. if we were _sure_ it was a dom0 issue this'd be a no-brainer. 17:24:42 tflink, ugh. dial back time ? 17:24:51 * adamw heads for the delorean 17:25:04 * tflink looks for plutonium for the delorean 17:25:17 darnok: do you have a feel for how common use of the different storage backends is, with xen? 17:25:37 i don't really have any idea whether people are 'mostly' using disk image files or 'mostly' using actual partitions/LVs/whatever 17:25:40 adamw, phy is the recommended. file is not b/c you don't get any data assurance. 17:25:47 okay... 17:26:11 adamw, That is until the direct IO patches for loop device are going to show up in the kernel.. circa v3.6 maybe? 17:26:22 i always use lvs for virt guests but i dont use xen 17:26:33 well, if we're tentatively considering this a dom0 issue and file isn't the recommended backend in any case, i'm kinda happy with -1 blocker on this. 17:26:47 adamw: same here 17:27:35 probably worth noting in known issues 17:28:12 darnok: what's your feel? 17:28:13 c #8 tflink tested with domu and its working 17:28:30 akshayvyas: yeah, konrad says that's not entirely conclusive yet, that's what we were discussing a minute ago 17:28:31 adamw, I am leaning towards dom0 being an issue but I hate feeling like an idiot if I am wrong. 17:28:41 proposed #agreed - 824641 - RejectedBlocker - This appears to be a Dom0 issue instead of a DomU issue which does not violate any of the Fedora 17 release criteria. In addition, the use of file:// storage backends is not recommended and phy:// storage backends do not seem affected by this bug 17:28:44 darnok: heh =) 17:29:09 * tflink can change if we decide otherwise 17:29:09 darnok: life sucks sometimes when you're working with our release schedules... 17:29:25 tflink: ack 17:29:39 given that we really have to make a call right now, i'm okay going with that. ack 17:29:51 tflink: ack if its working with domu 17:30:12 ec2 works which is my domU test case 17:30:31 adamw, It is just that it is merge window time, hence the lack of 100% focus on it. 17:30:42 darnok: i see 17:31:15 tflink: ack 17:32:04 ack 17:32:49 dgilmore: do you remember which kernel was in the last EC2 test images? 17:32:58 ack 17:33:37 tflink: it was the RC1 package set 17:33:47 on second thought, it doesn't matter what was in the AMIs 17:33:51 AMIs wouldn't hit this 17:34:03 at least not in the same way 17:34:24 #agreed - 824641 - RejectedBlocker - This appears to be a Dom0 issue instead of a DomU issue which does not violate any of the Fedora 17 release criteria. In addition, the use of file:// storage backends is not recommended and phy:// storage backends do not seem affected by this bug 17:34:25 tflink: if we were hitting it i hope we would have heard 17:34:37 dgilmore: I didn't do much IO in my EC2 testing 17:34:50 not heavy I/O anyways 17:34:59 OK, that would be all of the proposed blockers 17:35:01 tflink: me either 17:35:07 praise the lord 17:35:11 my testing was very basic 17:35:16 so we have 0 unresolved blockers at this point 17:35:24 so that's a good sign :) 17:35:27 * dgilmore votes +1 to go 17:35:29 rbergero: you beat me to it :) 17:35:34 #topic Release Criteria and Test Matrices 17:35:56 tflink: do you have these links handy, otherwise I can dig them up while you type about how complete and beautiful they are i hope :) 17:36:14 #link https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Install 17:36:27 install has one gap: scsi, which is always missing lately 17:36:28 #link https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Desktop 17:36:35 we need to do something about that. we could probably stop caring about it, because really, scsi. 17:36:47 adamw: the only one that concerns me a little is the lack of i386 usb media results 17:36:51 quite a lot of the results are pulled from rc3, note, which is fine because the rc3/rc4 delta is tiny. 17:37:15 tflink: we have a live dd pass i386 for rc3 17:37:33 we do? nvm, then - hadn't looked back at the older matrices 17:37:33 and a liveusb-creator pass for rc1 17:37:58 32-bit litd is missing, but...i can't think of any reason it'd be bust. 17:38:07 base is 100% 17:38:16 desktop is missing KDE update installation, which i'm about to test 17:40:42 ...aaaand it works. happily. 17:41:11 :) 17:41:19 there are some 'fails' noted in the install and desktop matrix 17:41:23 none of them are really blockers 17:41:31 i can cover 'em case-by-case briefly if wanted 17:41:42 adamw: your call 17:41:52 well, quickly 17:42:13 adamw: yes, let's, quickly :) 17:42:21 just so there's no "nobody talked about it" 17:43:51 from desktop: 812776 is one where network settings crashes in a very specific scenario the criteria don't cover. 823755 appears to be unreproducible by other testers or the reporter trying again, it's closed. 824820 is to do with file associations, doesn't hit the criteria (should probably be marked as 'warn' not 'fail'). 17:44:19 813257...that should technically be a blocker, so we should probably explicitly waive it. it's a bug in one fairly unimportant app that's a part of kdepim. 17:44:28 the usual fix would be to drop the app, but we really can't, as it's part of kdepim. 17:45:22 so, i'm assuming no-one wants to drop kdepim from KDE or wait indefinitely for upstream to fix ktimetracker... 17:45:38 correct. 17:45:41 okay! 17:45:43 as tempting as those are ... no, not really 17:46:13 #info 813257 is waived as a blocker as the only options are to wait indefinitely for a fix or drop kdepim entirely; we can't just drop the offending application as it's part of kdepim, which we need 17:46:47 unfortunately...i just saw 819275 , which i'm having somewhat more trouble rationalizing. i have no idea why it didn't come up before now. 17:48:30 well, it seems to work on my desktop... 17:48:54 can anyone else try running gnome-system-log from the overview? 17:49:19 * tflink might take a bit, needs to swap out disks 17:50:01 okay, come back to that 17:50:03 moving on... 17:50:22 * rbergero crosses toes 17:50:46 820797 relates specifically to VirtualBox's EFI support. actual EFI systems in general work fine. so we're not hugely concerned about that one. 17:51:14 820472 was a false positive from the dependency check script. 17:51:24 824191 we've discussed here and rejected. 17:51:39 796899 we've rejected previously as a blocker, it's just an annoyance. 17:51:49 824641 we've discussed here and rejected. 17:52:10 820351 we've discussed and accepted as NTH but rejected as blocker, it's the bug about sometimes not getting an F17 kernel when upgrading 17:52:29 815473 is the preupgrade bug about not updating the grub menu, it's already rejected as a blocker. 17:52:36 so that's all the bugs listed on the matrices. 17:53:08 okay, so are we hanging out for a moment on tflink and 819275? 17:53:14 coming back to 819275... 17:53:20 yeah, and me, i'm running a desktop install quickly 17:53:41 i can't reproduce the problem. either on my 'dirty' desktop or in a 'clean' install from 17rc4 live desktop. 17:53:52 i get a PK prompt for my user password, i enter it, log viewer runs. 17:54:03 mclasen obviously believes there's a bug there, but for me it works... 17:54:38 this box picked the perfect time to decide it needed to run fsck at boot but now that it's done - I can run gnome-system-log w/o issue from the overview 17:54:54 okay. good enough for me. 17:55:12 for the record, this is not a 100% clean RC4 install 17:56:04 i can reproduce the alt-f2 fail, but that doesn't hit criteria. 17:56:11 hum - the reporter was reporting from fallback mode, it seems 17:56:30 * adamw forces fallback 17:56:55 ah, okay. i can reproduce the problem with fallback mode. 17:57:24 same here 17:57:39 so...i'm inclined to say -1 blocker as fallback is much less important than it used to be 17:58:04 there are also workarounds, if I'm reading that bug correctly 17:58:05 we kinda considered fallback to be a release blocking desktop in its own right since shell landed, because lots of people wound up with it 17:58:12 'run it from a console' 17:58:19 exactly 17:58:27 but with 17, fallback mode is really only going to happen if you explicitly force it, or you have blacklisted hardware 17:58:58 the criterion about all apps running by default is mainly a polish criterion, the idea being it's the kind of thing people check 17:59:10 but since people mostly aren't gonna be in fallback mode...doesn't seem like a huge issue. 17:59:47 the criterion is "All applications listed under the Applications menu or category must start successfully", for the record. the criterion applies "to all release-blocking desktops". 17:59:58 i'm fine with saying 'it works in shell'. 18:00:09 do we want a vote? 18:00:35 I'd be willing to bet that there are more people running either XFCE or LXDE than fallback and this wouldn't block release if it was in one of those 18:00:42 * rbergero agrees with tflink 18:00:43 just to restate what adam was talking about 18:01:09 i think i can +1 what adam said re: it works in shell 18:01:25 we never officially established the status of fallback mode, note 18:01:30 so we have some wiggle room there =) 18:01:33 +1 to 'works in shell' 18:01:40 we're not breaking any rules 18:02:48 damnit, i love breaking rules 18:02:53 adamw: im fine with what you said 18:02:57 okay, so i thik we are clear then 18:03:09 yaay 18:03:31 #info 819275 agreed not to be worthy of blocker consideration as it affects fallback mode only, and fallback mode is niche now 18:03:57 so with that...the matrices are complete with the sole exception of scsi, which we always waive. 18:04:06 * rbergero nods 18:04:17 moving onwards, then? 18:04:19 yes! 18:04:32 #topic Ship or not to ship, that is the question 18:04:42 * dgilmore votes ship 18:04:46 * nirik is also a +1 to go. Lets ship it! 18:04:55 adamw, tflink, kparal: does qa have any objections, with matrices complete and blockers clear? 18:05:26 nope, we've waived all the potential issues and have no unresolved blockers - qa is go 18:05:37 yup, as per our policy, we're gooooo 18:05:56 #agreed We shall ship the Beefy Miracle (aka F17) on Tuesday, May 29 18:06:05 :D woohoo 18:06:07 * akshayvyas says go go fedora 17 18:06:19 * kparal goes partying 18:06:37 Nice job guys. +1 18:06:48 good job everyone :) 18:07:16 okay. 18:07:18 thanks everyone .:) 18:07:23 #endmeeting