fedora_17_final_go_nogo_meeting_round_2
LOGS
17:01:09 <rbergeron> #startmeeting Fedora 17 Final Go NoGo Meeting Round 2
17:01:09 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:40 * satellit_Tris55R listening
17:03:26 <rbergero> dude.
17:03:45 * nirik waves
17:03:54 <rbergero> My irc host just died. Rather inconvenient as I hadn't chaired anyone.
17:04:21 <rbergero> me hrms
17:04:22 <tflink> rbergero: I think you can get an admin to add a chair
17:04:29 <nirik> I can do it.
17:04:32 <rbergero> nirik: thank you
17:04:47 <rbergero> sorry for the idiocy / inconvenience, just wanted to make sure we started this meeting off awesomely
17:04:56 <dgilmore> rbergero: ;)
17:05:09 <akshayvyas> i think it will be gogo today
17:05:14 <nirik> addchair #fedora-meeting-1 freenode rbergero
17:05:20 <nirik> .addchair #fedora-meeting-1 freenode rbergero
17:05:20 <zodbot> nirik: Chair added: rbergero on (#fedora-meeting-1, freenode).
17:05:23 <rbergero> woot
17:05:28 <rbergero> #chair adamw dgilmore tflink nirik
17:05:28 <zodbot> Current chairs: adamw dgilmore nirik rbergero rbergeron tflink
17:05:38 <rbergero> #meetingname Fedora 17 Final Go NoGo Meeting Round 2
17:05:38 <zodbot> The meeting name has been set to 'fedora_17_final_go_nogo_meeting_round_2'
17:05:46 <rbergero> #topic Why are we here
17:05:51 <rbergero> Okay, going to sing the usual song here:
17:06:54 <rbergero> #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 <rbergero> Any questions?
17:07:18 <rbergero> We'll hit these areas one at a time, more or less.
17:07:23 <rbergero> #topic Blocker Bugs
17:07:27 <rbergero> tflink: greetings sir
17:08:03 <tflink> ATM, we have 2 proposed blockers to deal with
17:08:13 <tflink> the 1 accepted blocker is VERIFIED
17:08:21 <tflink> #link http://fedoraproject.org/wiki/Current_Release_Blockers
17:08:27 <tflink> which I just updated before the meeting
17:08:31 <rbergero> tflink: i see that
17:09:10 <tflink> 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 <adamw> so https://admin.fedoraproject.org/updates/anaconda-17.29-1.fc17 needs to get pushed stable
17:09:14 <rbergero> want to walk us through them? :)
17:09:20 <rbergero> dgilmore: refresh
17:09:32 <tflink> #topic (824191) nfsiso install hangs during reboot
17:09:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=824191
17:09:32 <tflink> #info Proposed Blocker, NEW
17:09:32 <rbergero> dgilmore: that happens to me all the time :)
17:09:59 <tflink> this one is a little interesting
17:10:35 <rbergero> 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. <golfclapwithsarcasm> :)
17:10:52 <tflink> the votes in the bug seem to be mostly -1 blocker
17:10:56 <adamw> eh, we have searches.
17:11:09 <tflink> adamw: we do now, they didn't work for a couple days there
17:11:15 <tflink> :)
17:11:18 <adamw> you can tell how hard i'm working!
17:11:36 <adamw> so when we hit this bug i started thinking of jlaska's 'point of diminishing returns'
17:11:52 <tflink> 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 <dgilmore> im -1 blocker. not ideal. but reset teh system and its ok
17:12:12 <tflink> 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 <adamw> 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 <dgilmore> adamw: right
17:12:39 * kparal takes notes
17:12:45 <adamw> 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 <rbergero> adamw: yup
17:13:17 <akshayvyas> adamw: right
17:14:02 <adamw> 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 <tflink> 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 <adamw> yeah, i just don't see this completely killing anyone, no matter how hard i try.
17:15:32 <adamw> so...shall we vote?
17:15:38 <dgilmore> tflink: right, plenty of ways to not hit it
17:15:46 <dgilmore> adamw: -1 blocker -1 nth
17:16:07 * nirik is also -1, -1
17:16:07 <mbroyles__> #agreed
17:16:18 <red_alert> also, kickstart installations over nfs (without repo= boot option) seem to work fine
17:16:21 <adamw> -1/-1
17:16:22 <kparal> adamw: rvykydal said the same, updates.img can touch the whole system
17:16:38 <adamw> 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 <tflink> 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 <tflink> ack/nak/patch?
17:17:22 <adamw> ack
17:17:26 <akshayvyas> ack
17:17:27 <red_alert> s/isntall/install/ ;)
17:17:31 <mbroyles__> ack
17:17:40 <red_alert> ack
17:17:45 <tflink> 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 <dgilmore> ack
17:18:04 <tflink> red_alert: good catch, I've been doing that for the last week or 2. not sure why
17:18:12 <tflink> #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 <adamw> still ack =)
17:18:29 <tflink> #topic (824641) kernel 3.3 crashes with blk_dump_rq_flags+ when using a file:/// backend instead of phy:// backend
17:18:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=824641
17:18:35 <tflink> #info Proposed Blocker, NEW
17:18:46 <rbergero> lol
17:18:46 <rbergero> ack
17:19:22 <tflink> 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 <adamw> as long as we're sure of that, i'm okay
17:19:37 <adamw> though the latest comment on the bug seems more equivocal
17:19:41 <adamw> not sure how that relates to your test
17:20:10 <tflink> adamw: which comment?
17:20:15 <darnok> can I chime in?
17:20:21 <tflink> sure, go for it
17:20:27 <dgilmore> ec2 works ok
17:20:27 <darnok> btw, this is konrad.
17:20:33 <rbergero> ;)
17:20:49 <adamw> hey backwards konrad
17:20:57 <adamw> for anyone playing along at home, konrad is our pet xen expert =)
17:21:19 <darnok> 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 <darnok> 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 <tflink> darnok: if it was a problem in domU, wouldn't my test w/ F16 Dom0 have failed?
17:21:53 <adamw> 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 <dgilmore> xen is almost teh same between f16 and f17
17:22:56 <darnok> 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 <darnok> tflink, And also on the whole how the block system has changed between f16 and f17.
17:23:44 <darnok> tflink, But I am leaning towards it being a dom0 issue.
17:24:09 <darnok> tflink, And there is a workaround - just use 'phy'  (so LVM or raw partition).
17:24:13 <akshayvyas> well C #4 says that criterion only covers usage as a DomU.
17:24:22 <tflink> 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 <adamw> akshayvyas: right. if we were _sure_ it was a dom0 issue this'd be a no-brainer.
17:24:42 <darnok> 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 <adamw> darnok: do you have a feel for how common use of the different storage backends is, with xen?
17:25:37 <adamw> 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 <darnok> adamw, phy is the recommended. file is not b/c you don't get any data assurance.
17:25:47 <adamw> okay...
17:26:11 <darnok> 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 <dgilmore> i always use lvs for virt guests but i dont use xen
17:26:33 <adamw> 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 <dgilmore> adamw: same here
17:27:35 <dgilmore> probably worth noting in known issues
17:28:12 <adamw> darnok: what's your feel?
17:28:13 <akshayvyas> c #8 tflink tested with domu and its working
17:28:30 <adamw> akshayvyas: yeah, konrad says that's not entirely conclusive yet, that's what we were discussing a minute ago
17:28:31 <darnok> adamw, I am leaning towards dom0 being an issue but I hate feeling like an idiot if I am wrong.
17:28:41 <tflink> 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 <adamw> darnok: heh =)
17:29:09 * tflink can change if we decide otherwise
17:29:09 <adamw> darnok: life sucks sometimes when you're working with our release schedules...
17:29:25 <dgilmore> tflink: ack
17:29:39 <adamw> given that we really have to make a call right now, i'm okay going with that. ack
17:29:51 <akshayvyas> tflink: ack if its working with domu
17:30:12 <dgilmore> ec2 works  which is my domU test case
17:30:31 <darnok> adamw, It is just that it is merge window time, hence the lack of 100% focus on it.
17:30:42 <adamw> darnok: i see
17:31:15 <red_alert> tflink: ack
17:32:04 <rbergero> ack
17:32:49 <tflink> dgilmore: do you remember which kernel was in the last EC2 test images?
17:32:58 <mbroyles__> ack
17:33:37 <dgilmore> tflink: it was the RC1 package set
17:33:47 <tflink> on second thought, it doesn't matter what was in the AMIs
17:33:51 <tflink> AMIs wouldn't hit this
17:34:03 <tflink> at least not in the same way
17:34:24 <tflink> #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 <dgilmore> tflink: if we were hitting it i hope we would have heard
17:34:37 <tflink> dgilmore: I didn't do much IO in my EC2 testing
17:34:50 <tflink> not heavy I/O anyways
17:34:59 <tflink> OK, that would be all of the proposed blockers
17:35:01 <dgilmore> tflink: me either
17:35:07 <rbergero> praise the lord
17:35:11 <dgilmore> my testing was very basic
17:35:16 <rbergero> so we have 0 unresolved blockers at this point
17:35:24 <rbergero> so that's a good sign :)
17:35:27 * dgilmore votes +1 to go
17:35:29 <tflink> rbergero: you beat me to it :)
17:35:34 <rbergero> #topic Release Criteria and Test Matrices
17:35:56 <rbergero> 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 <tflink> #link https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Install
17:36:27 <adamw> install has one gap: scsi, which is always missing lately
17:36:28 <tflink> #link https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Desktop
17:36:35 <adamw> we need to do something about that. we could probably stop caring about it, because really, scsi.
17:36:47 <tflink> adamw: the only one that concerns me a little is the lack of i386 usb media results
17:36:51 <adamw> quite a lot of the results are pulled from rc3, note, which is fine because the rc3/rc4 delta is tiny.
17:37:15 <adamw> tflink: we have a live dd pass i386 for rc3
17:37:33 <tflink> we do? nvm, then - hadn't looked back at the older matrices
17:37:33 <adamw> and a liveusb-creator pass for rc1
17:37:58 <adamw> 32-bit litd is missing, but...i can't think of any reason it'd be bust.
17:38:07 <adamw> base is 100%
17:38:16 <adamw> desktop is missing KDE update installation, which i'm about to test
17:40:42 <adamw> ...aaaand it works. happily.
17:41:11 <dgilmore> :)
17:41:19 <adamw> there are some 'fails' noted in the install and desktop matrix
17:41:23 <adamw> none of them are really blockers
17:41:31 <adamw> i can cover 'em case-by-case briefly if wanted
17:41:42 <dgilmore> adamw: your call
17:41:52 <adamw> well, quickly
17:42:13 <rbergero> adamw: yes, let's, quickly :)
17:42:21 <rbergero> just so there's no "nobody talked about it"
17:43:51 <adamw> 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 <adamw> 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 <adamw> the usual fix would be to drop the app, but we really can't, as it's part of kdepim.
17:45:22 <adamw> so, i'm assuming no-one wants to drop kdepim from KDE or wait indefinitely for upstream to fix ktimetracker...
17:45:38 <rbergero> correct.
17:45:41 <adamw> okay!
17:45:43 <tflink> as tempting as those are ... no, not really
17:46:13 <adamw> #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 <adamw> 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 <adamw> well, it seems to work on my desktop...
17:48:54 <adamw> 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 <adamw> okay, come back to that
17:50:03 <adamw> moving on...
17:50:22 * rbergero crosses toes
17:50:46 <adamw> 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 <adamw> 820472 was a false positive from the dependency check script.
17:51:24 <adamw> 824191 we've discussed here and rejected.
17:51:39 <adamw> 796899 we've rejected previously as a blocker, it's just an annoyance.
17:51:49 <adamw> 824641 we've discussed here and rejected.
17:52:10 <adamw> 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 <adamw> 815473 is the preupgrade bug about not updating the grub menu, it's already rejected as a blocker.
17:52:36 <adamw> so that's all the bugs listed on the matrices.
17:53:08 <rbergero> okay, so are we hanging out for a moment on tflink and 819275?
17:53:14 <adamw> coming back to 819275...
17:53:20 <adamw> yeah, and me, i'm running a desktop install quickly
17:53:41 <adamw> i can't reproduce the problem. either on my 'dirty' desktop or in a 'clean' install from 17rc4 live desktop.
17:53:52 <adamw> i get a PK prompt for my user password, i enter it, log viewer runs.
17:54:03 <adamw> mclasen obviously believes there's a bug there, but for me it works...
17:54:38 <tflink> 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 <adamw> okay. good enough for me.
17:55:12 <tflink> for the record, this is not a 100% clean RC4 install
17:56:04 <adamw> i can reproduce the alt-f2 fail, but that doesn't hit criteria.
17:56:11 <adamw> hum - the reporter was reporting from fallback mode, it seems
17:56:30 * adamw forces fallback
17:56:55 <adamw> ah, okay. i can reproduce the problem with fallback mode.
17:57:24 <tflink> same here
17:57:39 <adamw> so...i'm inclined to say -1 blocker as fallback is much less important than it used to be
17:58:04 <tflink> there are also workarounds, if I'm reading that bug correctly
17:58:05 <adamw> 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 <adamw> 'run it from a console'
17:58:19 <tflink> exactly
17:58:27 <adamw> but with 17, fallback mode is really only going to happen if you explicitly force it, or you have blacklisted hardware
17:58:58 <adamw> 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 <adamw> but since people mostly aren't gonna be in fallback mode...doesn't seem like a huge issue.
17:59:47 <adamw> 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 <adamw> i'm fine with saying 'it works in shell'.
18:00:09 <adamw> do we want a vote?
18:00:35 <tflink> 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 <tflink> just to restate what adam was talking about
18:01:09 <rbergero> i think i can +1 what adam said re: it works in shell
18:01:25 <adamw> we never officially established the status of fallback mode, note
18:01:30 <adamw> so we have some wiggle room there =)
18:01:33 <tflink> +1 to 'works in shell'
18:01:40 <adamw> we're not breaking any rules
18:02:48 <rbergero> damnit, i love breaking rules
18:02:53 <dgilmore> adamw: im fine with what you said
18:02:57 <rbergero> okay, so i thik we are clear then
18:03:09 <adamw> yaay
18:03:31 <adamw> #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 <adamw> 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 <rbergero> moving onwards, then?
18:04:19 <adamw> yes!
18:04:32 <rbergero> #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 <rbergero> adamw, tflink, kparal: does qa have any objections, with matrices complete and blockers clear?
18:05:26 <tflink> nope, we've waived all the potential issues and have no unresolved blockers - qa is go
18:05:37 <adamw> yup, as per our policy, we're gooooo
18:05:56 <rbergero> #agreed We shall ship the Beefy Miracle (aka F17) on Tuesday, May 29
18:06:05 <dgilmore> :D woohoo
18:06:07 * akshayvyas says go go fedora 17
18:06:19 * kparal goes partying
18:06:37 <ADSLLC> Nice job guys.  +1
18:06:48 <red_alert> good job everyone :)
18:07:16 <rbergero> okay.
18:07:18 <rbergero> thanks everyone .:)
18:07:23 <rbergero> #endmeeting