17:00:21 #startmeeting F20 Alpha Go/No-Go meeting #2 17:00:21 Meeting started Thu Sep 19 17:00:21 2013 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:21 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:28 #meetingname F20 Alpha Go/No-Go meeting #2 17:00:28 The meeting name has been set to 'f20_alpha_go/no-go_meeting_#2' 17:00:45 #topic Roll Call 17:00:59 hey, who's here for go/no-go fun? 17:01:04 * nirik waves 17:01:05 * tflink is here 17:01:06 morning 17:01:17 * roshi here 17:01:33 * mkrizek is here 17:01:39 * satellit listening 17:02:00 * thunderbirdtr sit corner and listen.. 17:02:08 . 17:02:16 let's wait a sec... 17:03:01 * pwhalen is here 17:03:34 #topic Purpose of this meeting 17:03:57 * Viking-Ice is here 17:04:26 #info Purpose of this meeting is to see whether or not F20 Alpha is ready for shipment, according to the release criteria. 17:04:26 #info This is determined in a few ways: 17:04:28 #info No remaining blocker bugs 17:04:29 #info Test matrices for Alpha are fully completed 17:04:31 #link http://qa.fedoraproject.org/blockerbugs/milestone/20/alpha/buglist 17:04:32 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC4_Install 17:04:34 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC4_Base 17:04:35 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC4_Desktop 17:05:17 well, let's start with blocker review 17:05:30 #chair tflink 17:05:30 Current chairs: jreznik tflink 17:05:37 tflink: may I ask you? 17:05:42 sure 17:05:50 (usual target) 17:06:34 #info up for review today, we have: 17:06:37 #info 3 Proposed Blockers 17:06:37 #info 2 Accepted Blockers 17:06:51 starting with the proposed blockers 17:07:02 #topic (1009278) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128) 17:07:04 #link https://bugzilla.redhat.com/show_bug.cgi?id=1009278 17:07:07 #info Proposed Blocker, anaconda, MODIFIED 17:07:16 This bug is an issue with adding keyboard layouts during live install 17:07:32 click on the '+' button in the keyboard spoke and crash 17:08:11 * kparal comes 17:08:15 * pschindl is here 17:08:41 the biggest issue here is how easy it is to hit 17:08:58 the crash doesn't seem to happen for DVD/netinstall 17:09:00 my brain might have been fried last night - but I didn't see this on i686 17:09:11 * roshi re-checks 17:09:15 roshi: livecd adding keyboard layouts? 17:09:20 yeah 17:09:26 I'm leaning towards +1 due to it's easy to hit 17:09:33 * kparal checks 17:10:15 * nirik reads up on it. 17:10:30 crashes for me even with 32bit Live 17:10:49 it's in python, so it should crash on both archs 17:11:19 kparal: yeah, fix is one liner just .decode("utf-8") 17:11:44 fun. 17:11:49 what critera does this hit? 17:12:32 I'd put it as a conditional violation of "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." 17:12:43 F20 alpha release criteria for installs using a non-en-us keyboard: "The installer must run when launched normally from the release-blocking images." 17:13:04 yep - brain was fried 17:13:11 it just crashed :) 17:13:37 * nirik agrees it's a nasty one. Don't look forward to another week slip for a 1 line change tho. ;( 17:14:03 such is life 17:14:20 well, we respun for bigger issues and were able to release 17:14:34 just it should not happen that such crasher is found so late... 17:14:47 jreznik: it's a very late regression 17:14:48 so this only affects lives? 17:14:49 this is a regression 17:14:57 it appears to be a regression between RC2 and RC3 17:15:36 kparal: it is but first rc3 live install test should show it 17:15:54 jreznik: it was reported, just not marked as a blocker 17:16:09 jreznik: we don't visit all dialogs for every compose 17:16:23 sorry, ot now 17:16:37 can't we just do an rc5 with the fix and retest? 17:16:41 (and yes, dogtail, hint :) 17:16:53 if the fix is _that_ limited, we could actually respin and transfer most results from rc4 17:16:56 and at worst slip one day not a full week again *sigh* 17:17:00 drago01, just like that 17:17:01 drago01: if we start moving now, it should be possible 17:17:14 so ideas? workaround, votes... 17:17:29 jreznik: can anaconda make a build with just this single fix, nothing else? 17:17:37 the workarounds would be to not change keyboard layout during live install 17:17:38 well the workaround is obvious dont change the keyboard 17:17:52 if you need to set up a keyboard, use the DVD or netinstall 17:18:02 or just do it after install 17:18:20 I'd rather spin up TC5 and test it very fast, then release TC4 17:18:35 er, RC 17:18:45 kparal: whats the point? 17:18:47 should we hit the rest of the blockers before we start thinking about a rushed RC5? or am I missing something? 17:18:54 kparal: why would we release rc4 then? 17:18:59 (which is possible) 17:19:06 drago01: sorry, then->than 17:19:18 if it's also live, we could also just respin lives? thats kinda gross tho 17:19:24 rc5 means retest everything if we are hitting regression between rc it might bring about other regressions 17:19:48 * nirik nods. 17:19:50 yeah, the RCX.1 spins in the past have been less than optimal 17:20:04 Viking-Ice: that's why I'm checking if we can have just isolated anaconda build... 17:20:04 Viking-Ice: unlikely if we do just the one line anaconda fix .. 17:20:06 let's go through the rest as roshi proposes and revisited it afterwards 17:20:22 Viking-Ice: for that one line change? normally I'd agree with you somewhat but that looks like a _very_ isolated change 17:20:27 isolated and simple 17:20:41 famous last words, I know 17:20:42 we might be wasting time discussing this if we end up having to do rc5 anyway 17:20:50 yep 17:20:53 yah 17:21:00 * nirik nods again 17:21:18 let's go quick through the rest, if not other blocker - let's talk about rc5 17:21:57 #info there seems to be interest in doing a quick RC5 for just this fix but we want to go through the other proposed blockers to see if there are other accepted and unaddressed blockers 17:22:11 #info will revisit this bug after discussing and deciding on the others 17:22:19 moving on ... 17:22:28 #topic (1009833) initial-setup fails to run on F20 Alpha RC4 ARM minimal image on Trimslice 17:22:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1009833 17:22:34 #info Proposed Blocker, initial-setup, NEW 17:22:53 this is the expected behavior of initial-setup-text 17:22:55 "Release-blocking ARM disk images must boot to the initial-setup utility. " 17:23:09 this hadn't been reported as a blocker up until now because the behavior was expected 17:23:11 it runs on the serial console. 17:23:17 and only the serial console 17:23:31 if you boot the minimal arm image and don't have the serial console hooked up, you're out of luck 17:23:33 sounds like a good release note? 17:23:33 is it expected to run only on the serial console 17:23:52 graphical initial-setup runs fine on the KDE arm image 17:23:55 nirik, depends if this is the most common way of doing ti 17:24:02 do we need secretary duty for this? /me will update bugs if they need it 17:24:08 Viking-Ice, it is.. 17:24:11 roshi: thanks 17:24:13 well, sounds like it is to me, yes. 17:24:23 pwhalen: is that expected to change after alpha? 17:24:25 pwhalen, so the most common way is to have an serial console 17:24:35 nirik, its not to my knowledge 17:24:39 ok 17:25:11 at the least, I agree that releasenotes/commonbugs are needed here 17:25:13 so -1 and a line in the release notes 17:25:21 so it seems like expected behaviour, at least for now - release notes/common bugs; -1 blocker 17:25:32 -1 blocker 17:25:36 -1 blocker 17:25:46 adam and I would have been spinning our wheels for a while last night if I didn't always hook up the serial console to my trimslice 17:25:50 -1 17:26:35 -1 17:26:55 -1 17:26:58 proposed #agreed 1009833 - RejectedBlocker - While unfortunate, initial-setup appearing only on the serial console is expected behavior and thus, this bug is rejected as a blocker for F20 alpha. However, it should be documented in some combination of release notes and commonbugs 17:27:01 ack 17:27:03 ack 17:27:03 ack/nak/patch? 17:27:09 ack 17:27:13 ack 17:27:14 ack 17:27:17 ack 17:27:21 #agreed 1009833 - RejectedBlocker - While unfortunate, initial-setup appearing only on the serial console is expected behavior and thus, this bug is rejected as a blocker for F20 alpha. However, it should be documented in some combination of release notes and commonbugs 17:27:31 #topic (1009828) UEFI boot menu doesn't contain safe graphics mode 17:27:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1009828 17:27:31 #info Proposed Blocker, LiveCD, NEW 17:27:51 we already had this one for f19 alpha reported by kparal :) 17:28:05 safe mode at alpha 17:28:08 lol 17:28:10 -1 17:28:14 blocker 17:28:32 what's sad - we are not very good to push bugs like this to be fixed by next release :( 17:28:54 that's why I intend to propose it at least for Final, if we reject it now 17:29:01 kparal: +1 17:29:14 (and make sure someone would push it) 17:29:30 it sounds like a non-trivial fix as well 17:29:32 * nirik is -1 alpha blocker, but yeah, we should fix it. 17:29:32 at least to me 17:29:46 please note that even if we fix this bug, there are several more bugs related to safe grapics on uefi (jsedlak will report them soon), so this single fix solves nothing at all 17:29:59 -1 blocker 17:30:06 -1 blocker 17:30:08 -1 blocker 17:30:09 kparal: being able to load vesa drivers explicitly? 17:30:14 -1 blocker 17:30:22 -1 blocker 17:30:22 tflink: vesa doesn't work on uefi, mostly 17:30:58 tflink: instead, the menu has to specify fbdev. or maybe something else, I don't have the expertise 17:31:30 proposed #agreed 1009828 - RejectedBlocker - While unfortunate, basic video drivers have not ever worked on UEFI machines and this is not a regression in functionality. Therefore rejected as a release blocking bug for F20 alpha 17:31:32 ack 17:31:35 ack 17:31:40 ack 17:31:41 ack 17:31:45 ack 17:31:51 ack 17:31:55 #agreed 1009828 - RejectedBlocker - While unfortunate, basic video drivers have not ever worked on UEFI machines and this is not a regression in functionality. Therefore rejected as a release blocking bug for F20 alpha 17:32:44 which brings us back to ... 17:33:00 well, we do have 2 accepted blockers but those are VERIFIED 17:33:05 so given that we are not forced to respin for any more serious is I'm -1 to rc5 and think we should just mention it in the release 17:33:16 does anyone want to go over them before getting back to the keyboard bug? 17:33:21 s/is/isssue 17:33:44 * tflink takes that as a no 17:33:53 #topic (1009278) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128) 17:33:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=1009278 17:33:58 #info Proposed Blocker, anaconda, MODIFIED 17:33:58 * nirik is kinda on the fence. It's a nasty bug, but I guess it is alpha... 17:34:33 it's alpha with an easy workarounds 17:34:48 same here, and workaround is to use DVD in case you really want your keyboard 17:34:55 I don't think that we should block alpha because of this bug. 17:34:58 yeah, but then you have to download the dvd 17:35:02 can/did someone else confirm that the DVD/netinstall works? 17:35:06 or netinst 17:35:17 nirik, or just change it afterwards 17:35:20 tflink: netinst works, I tested it 17:35:25 could we also do a updates.img? 17:35:41 or not risk hitting more regressions 17:35:44 kparal: ok, just making sure someone else had tried it :) 17:35:58 I don't remember if we can do updates.img in a livecd 17:36:11 or... for that matter, 'yum update anaconda' on the live media and running it should work provided we get the fixed one in updates-testing no? 17:36:19 since this only affects lives, another workaround would be to update anaconda before attempting install 17:36:24 yeah 17:36:28 yep 17:36:39 which makes me lean more -= 17:36:40 -1 17:36:44 yeah, me too. 17:36:58 -1 from me too 17:37:01 -1 17:37:04 -1 17:37:05 -1 17:37:14 not a nice bug, simple fix but also bcl told me we would have to accept three more fixes to get build 17:37:17 -1 17:37:20 ok, -1... common bugs and workarounds. 17:37:31 -1 17:37:35 I still believe we should resping, but I'm overvoted 17:37:36 But if it means that kparal will beat us tomorrow I'm +1 :) 17:37:41 *respin 17:37:43 oh wait how did the cloud testing go? 17:37:45 * roshi snickers at "since this only affects lives" 17:37:55 Viking-Ice: openstack was good/fine. 17:38:10 I think tflink tested ami's 17:38:21 really ? 17:38:29 proposed #agreed 1009278 - RejectedBlocker - While nasty, this only affects live images and there are acceptable workarounds (update anaconda before install, use DVD/netinstall) this isn't serious enough to block release of F20 alpha and is rejected as a release blocking bug. 17:38:48 ack 17:38:59 kparal: there are three more fixes, one to custom spoke, one for username tui validation, not sure about third, so should be doable but with workarounds and only lives affected... 17:39:00 Viking-Ice: yeah, I did some basic testing of the RC4 amis 17:39:10 ack 17:39:14 ack 17:39:19 ack 17:39:24 ack 17:39:32 ack 17:39:36 ackey 17:39:37 jreznik: Lives are what most people care about 17:40:16 #agreed 1009278 - RejectedBlocker - While nasty, this only affects live images and there are acceptable workarounds (update anaconda before install, use DVD/netinstall). Therefore, it was decided that this isn't serious enough to block release of F20 alpha and is rejected as a release blocking bug. 17:40:23 * tflink made a slight change in the grammar 17:40:36 will undo and re-propose if anyone disagrees with it 17:40:54 kparal: I'd be with you and I expected us to go that route but if "simple" anaconda update is enough... I care more about - how to avoid this kind of bugs appear so late (and again mention dogtail...) 17:41:13 looks good to me tflink 17:41:21 jreznik: we're well aware of dogtail 17:41:43 jreznik: well let's ask then if the relevant code had to be updated between RC2 and RC3... ;) 17:42:05 https://git.fedorahosted.org/cgit/anaconda.git/log/pyanaconda/keyboard.py 17:42:25 tflink, kparal: sorry, I'm just in a bit bad mood - not feeling very well, don't want to sound offensive to you :) 17:43:04 hey let's move on we can deal with how to prevent this and yata yata on QA meeting or on list 17:43:09 tflink: it was 17:43:19 Viking-Ice: sure, sorry 17:43:23 works for me 17:44:03 can I move on? 17:44:35 silence means yes 17:44:35 please 17:44:42 #topic Test Matrices coverage 17:45:24 guys, are you ok with current coverage (looks solid to me) 17:46:01 yep 17:46:16 the only potential snag is lack of DVD optical media testing 17:46:23 yeah I saw that 17:46:36 but we have +3 on test@ to push that off until beta when the images are required to be properly sized 17:46:45 true 17:47:05 well actually arguably sizing issue should be taking care of at alpha 17:47:08 not beta 17:47:16 but anyway lets move on 17:47:53 #info DVD optical media coverage is concern but +3 on test@ to push that off until beta when the images are required to be properly sized 17:48:17 Viking-Ice: yeah, that would be another option but I think it's too late to be moving criteria like that from beta to alpha 17:48:40 at this point anyway 17:48:57 other than that, the matrices look good to me 17:49:15 #info otherwise QA is ok with F20 Alpha RC4 Test Matrices coverage 17:49:23 anything else? 17:49:31 not from me 17:49:42 ok, let's move on 17:49:54 #topic Go/No-Go decision 17:50:25 +1 go. 17:50:31 +1 17:50:33 +1 go 17:50:37 +1 17:50:42 +1 17:51:47 matrices are OK and no unaddressed blockers. therefore, QA is GO 17:52:00 #info devel is Go 17:52:16 #info QA is Go (matrices are OK and no unaddressed blockers) 17:53:32 proposal #agreed Devel and QA votes Go for Fedora 20 Alpha (RC4) as matrices are covered and there are no unaddressed blocker bugs 17:53:44 releng is go 17:53:46 ack 17:53:47 ack 17:53:50 ack 17:53:51 ack 17:53:55 ack 17:53:56 ack 17:54:20 fpgm based on qa/devel/releng votes is go to (just for the record) 17:54:33 #agreed Devel and QA votes Go for Fedora 20 Alpha (RC4) as matrices are covered and there are no unaddressed blocker bugs 17:55:42 nice, thank you guys 17:55:55 * jreznik should use a bit of pirate talk but he's not pirate at all 17:56:12 jreznik: just add "me matey" to the end of something 17:56:26 dgilmore, nirik: for release announcement - who would be the person to send it as dgilmore is going to be out? 17:56:34 jreznik: nirik 17:56:48 ok 17:56:52 I can. 17:57:06 thanks, better than "at" :) 17:57:24 jreznik: at would work fine ;) 17:57:50 #action nirik to send release announcement on the Fedora 20 Alpha release day (2013-09-24) 17:58:24 ok, anything else? otherwise I'll set tflink's patented fuse 17:58:33 and thanks for coming! 17:58:38 wait arent we like missing a bunch of teams 17:58:40 damn patents 17:58:45 like doc the ok from fpl and what not 17:59:02 Viking-Ice: Go/No-Go is currently defined as Devel and QA 17:59:03 * tflink makes note to send licensing invoice to jreznik for usage of the patented fuse :) 17:59:11 jreznik: since when? 17:59:13 that's why adamw does not like if I say Go :) 17:59:17 "Development, QA, and Release Engineering" 17:59:28 https://fedoraproject.org/wiki/Go_No_Go_Meeting?rd=Engineering_Readiness_Meetings 17:59:30 dgilmore, nirik: ok, sorry for missing dgilmore 18:00:07 hm maybe docs should be here with us 18:00:18 Viking-Ice: there's readiness meeting 18:00:25 already then 18:00:32 mean alrighty then 18:00:48 and for Alpha, not much docs is done at all (we just have to make sure bugs are covered on common bugs page) 18:01:16 time for Board meeting... 18:01:19 3... 18:02:12 #action jreznik to announce Go decision 18:02:15 2... 18:02:50 1... 18:03:09 thanks again! 18:03:11 #endmeeting