17:03:34 #startmeeting F20 Alpha Go/No-Go meeting 17:03:34 Meeting started Thu Sep 12 17:03:34 2013 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:03:47 #meetingname F19 Alpha Go/No-Go meeting 17:03:47 The meeting name has been set to 'f19_alpha_go/no-go_meeting' 17:03:57 #topic Roll Call 17:04:02 Shouldn't it be F20? 17:04:09 #undo 17:04:09 Removing item from minutes: 17:04:16 #undo 17:04:20 * handsome_pirate waves from the crow's nest 17:04:27 #meetingname F20 Alpha Go/No-Go meeting 17:04:27 The meeting name has been set to 'f20_alpha_go/no-go_meeting' 17:04:33 * roshi here 17:04:42 pschindl: good catch, ctrl+c/v issue 17:04:53 jreznik: I thought so :) 17:05:07 let's get a few moments for other people to join us 17:05:11 * pschindl is here 17:05:19 * mkrizek is here 17:05:20 * suehle is here 17:05:23 * spoore is lurking 17:05:30 * handsome_pirate waves from the crow's nest 17:05:37 Sorry. took me a while to scroll back up to see where we went :) 17:05:39 #info just a reminder - Readiness meeting follows in two hours later, even we say No-Go today 17:05:52 * nirik is here 17:05:56 Same channel? 17:06:30 rbergeron: I was very, very generous to fpc :) 17:06:54 * tflink is here 17:07:16 handsome_pirate: -1 but we will see how long will fpc discuss scls :) 17:07:34 rog-o 17:07:37 #chair rbergeron tflink pschindl nirik 17:07:37 Current chairs: jreznik nirik pschindl rbergeron tflink 17:07:52 #topic Purpose of this meeting 17:07:52 * satellit listening on f20 DVD install from DVD 17:08:09 #info Purpose of this meeting is to see whether or not F20 Alpha is ready for shipment, according to the release criteria. 17:08:11 #info This is determined in a few ways: 17:08:13 #info No remaining blocker bugs 17:08:14 #info Test matrices for Alpha are fully completed 17:08:15 #link http://qa.fedoraproject.org/blockerbugs/milestone/20/alpha/buglist 17:08:17 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC2_Install 17:08:18 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC2_Base 17:08:20 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC2_Desktop 17:09:09 and I think we can start now with mini blocker review - tflink, may I ask you? 17:09:14 sure 17:09:32 #info current F20 alpha blocker status is: 17:09:40 #info 3 Proposed Blockers 17:09:40 #info 10 Accepted Blockers 17:09:40 #info 2 Proposed Freeze Exceptions 17:09:40 #info 16 Accepted Freeze Exceptions 17:09:44 hrm 17:09:46 #undo 17:09:46 Removing item from minutes: 17:09:48 #undo 17:09:48 Removing item from minutes: 17:09:59 starting with the proposed blockers 17:10:07 #topic (1006113) anaconda unable to get update image 17:10:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1006113 17:10:08 #info Proposed Blocker, anaconda, NEW 17:10:21 I think this is a testcase error 17:10:44 and looking on install matrix, pschindl marked it as pass 17:10:46 I tried it today and updates definitely works just fine. 17:10:50 we need to update the test case, but I don't think this is a valid bug against anaconda 17:11:06 pschindl: with a different updates.img than the one in the testcase? 17:11:09 * handsome_pirate is -1 blocker do to epically old updates.img 17:11:19 Yes, I created my own one. 17:11:32 I will update test case. 17:11:40 #info the updates.img in the testcase in question is too old to be valid, the test case needs to be updated 17:12:22 proposed #agreed 1006113 - RejectedBlocker - While this would be a blocker for f20 alpha, the root cause is an out of date test case that needs to be updated and thus, does not block release of f20 alpha. 17:12:28 or do we just close it as invalid 17:12:28 ack 17:12:41 so the update images was unpacked in run/install/updates ? 17:12:54 ack 17:12:56 if so just close it as invalid 17:12:58 Viking-Ice: well, there and /tmp 17:13:01 does that test case normally (when working correctly) provide any feedback on things that *would* be blockers? 17:13:01 tflink: I vote close as invalid and update test case 17:13:25 rbergeron: yes, updates.img via http is a release criterion for alpha 17:13:58 but we know that it is working otherwise via the matrix. 17:14:10 rbergeron: yep, pschindl checked it 17:14:12 just wanted to make sure it wasn't rooting out anything else :) 17:14:14 rbergeron: yes, several people (including me) have gotten it to work 17:14:27 ack (or invalid, doesn't matter for me) 17:14:47 * nirik is fine with close invalid. 17:15:00 okay, mooooooving on (and i'm okay with invalid too, for the record) 17:15:20 of course with fixing the testcase 17:15:26 I just tried it one more time. And it works and updates are in /tmp/updates/ 17:15:26 #info this bug will be closed as invalid due to the out-of-date testcase 17:15:42 thanks pschindl 17:15:43 #action pschindl to coordinate updating the testcase 17:15:49 #undo 17:15:49 Removing item from minutes: 17:15:55 #action pschindl to coordinate updating the updates.img via http testcase 17:16:13 anything else before moving on? 17:16:18 no 17:16:23 #topic (1007387) ValueError: ('invalid size specification', '1.52587892899e-06 mb') 17:16:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=1007387 17:16:29 #info Proposed Blocker, anaconda, NEW 17:17:28 this is really easy to hit 17:17:35 +1 blocker 17:17:39 +1 blocker 17:17:47 * nirik reads 17:17:55 I don't like it, but I'm +1 too :( 17:17:57 +1 blocker 17:18:08 it's pretty bad looking, can be workarounded by deleting all (as Alpha says it does not have to preserve old data) but it's really easy to hit +1 17:18:18 +1 :/ 17:18:30 ugh. ;( 17:18:37 dlehman is already working on patch 17:18:39 proposed #agreed 1007387 - AcceptedBlocker - Violates the following F20 alpha release criterion: "The installer must be able to complete an installation to a single disk using automatic partitioning." 17:18:41 doubleugh 17:18:43 ack 17:18:44 ack 17:18:51 ack 17:18:53 ack 17:18:54 ack I sadly say 17:18:54 ack 17:18:58 #agreed 1007387 - AcceptedBlocker - Violates the following F20 alpha release criterion: "The installer must be able to complete an installation to a single disk using automatic partitioning." 17:19:11 #topic (1004889) AttributeError: 'FC3_Cdrom' object has no attribute 'noverifyssl' 17:19:12 but not sure we will be able to pick the patch up without significant retesting of partitioning... 17:19:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1004889 17:19:17 #info Proposed Blocker, pykickstart, VERIFIED 17:19:19 * satellit deleting each partition from bottom up and not usint all sems to work 17:19:31 this isn't as clear of a blocker 17:19:45 * tflink notes that it's already a freeze exception 17:20:01 is it in RC2 already or not? 17:20:05 and it's fixed 17:20:08 nvm 17:20:10 #undo 17:20:10 Removing item from minutes: 17:20:11 #undo 17:20:11 Removing item from minutes: 17:20:13 #undo 17:20:13 Removing item from minutes: 17:20:19 so, that's all of the proposed blockers 17:20:37 qa is already no-go, do we want to continue with the other unaddressed blocker? 17:20:41 ah, one new blocker to rule them all 17:20:52 we have an old one, too 17:20:56 tflink: for record, I'd go through unadressed accepted ones 17:21:07 ok, there's just one 17:21:14 yep, that one 17:21:16 #topic (1002737) initial-setup-graphical.service does not run - TypeError: Argument 1 does not allow None as a value 17:21:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=1002737 17:21:22 #info Accepted Blocker, initial-setup, ON_QA 17:22:03 the first crash was fixed but there was another place in the code not sanity checked 17:22:05 the issue here is that initial-setup isn't running on at least KDE arm images 17:22:17 so it should be one liner 17:22:21 still a blocker that needs to be fixed 17:22:25 Indeed 17:22:26 Viking-Ice: sure 17:23:00 vpodzime complains he does not have access to arm hw but while checking it, I think qemu-arm is not as bad 17:23:19 pwhalen provided tb to anaconda guys 17:23:25 jreznik, apparently there is a regression in the kernel that breaks qemu-arm 17:23:30 jreznik: he complained about speed of qemu 17:23:48 jwb: News to me 17:24:07 jreznik: does he have the tools he needs to fix the new issue? 17:24:24 tflink: it's pretty simple fix, one missing check 17:24:27 handsome_pirate: it was mentioned in the ARM meeting yesterday. happened between 3.11.0-3 and 3.11.0-300 17:24:40 ok 17:24:48 jwb: Ah, missed the meeting yesterday 17:25:01 #info developers are aware of the new issue, are working on a fix 17:25:30 #info the fix should be simple and this bug doesn't need any additional prodding 17:25:34 bcl just sent patch to try to pwhalen 17:25:50 anything else on this bug? 17:25:55 so that's all for blockers 17:26:32 yep 17:26:37 yay 17:26:46 all the rest of teh accepted blockers are just waiting for karma and push to stable 17:27:38 do we want try to get fixes built and retest? I'd say for the first anaconda one with not minor change I'd say it would require retesting of the most anaconda test cases 17:27:50 agreed 17:28:13 do we even have a build with a fix yet? 17:28:27 tflink: not yet, both fixes in progress 17:28:45 let's check first test matrices coverage, that can help us with decision 17:28:48 I'm not sure we'd have time to not slip at this point 17:28:57 +1 17:29:13 yep I'm pretty sure we need to slip 17:29:19 we wouldn't have RC3 for another ... 4 hours minimum? 17:29:37 And, that's assuming the fixes get done now 17:29:41 and we really should not be stressing us into making it 17:29:46 yeah, I said minimum 17:29:49 tflink: yep, minimum 17:29:49 * nirik nods. we are doomed again. slip. ;( 17:29:56 :/ 17:30:06 Viking-Ice: +1 to that. 17:30:13 i actually thought we were going to make it until that new anaconda bug showed up 17:30:24 do we still want to go over the matrices? 17:30:41 Viking-Ice: if it would be only that second bug, it would make sense to try but for the partitioning one bug - for sure, no 17:31:02 tflink: yep, to see where we're and where we can still hit another issues (we don't know about yet) 17:31:11 #topic Test Matrices coverage 17:31:22 the big problem is cloud images 17:31:27 biggest 17:31:33 there's a blocker there that I'm not sure how to file 17:31:35 #info biggeste problem are cloud images 17:31:43 #undo 17:31:43 Removing item from minutes: 17:31:44 i386 AMI is DOA 17:32:14 it would be nice if the cloud sig was helping to test the stuff that they want promoted more 17:32:27 actually they should be doing that stuff 17:32:53 * jreznik is pinging mattdm to join us 17:33:14 tflink: blocker that you're not sure how to file? 17:33:19 yeah, if we want it as prime offering, we need help 17:33:20 rbergeron: yeah, DOA AMI 17:34:04 yeah, that's +1 blocker 17:34:07 what does it mean (for dumb not cloud compatible me) 17:34:16 jreznik: the AMI can't boot 17:34:29 rbergeron: Also, we need to talk about making Amazon space available for testers 17:34:32 ok, better now 17:34:32 x64 is fine, i386 is borked 17:34:57 handsome_pirate: yeah cost $$$ 17:35:09 We shouldn't support i386 any more :) 17:35:10 if there is a free account to use for testing that would be helpful 17:35:12 the testing cost me less than USD .50 17:35:20 lol 17:35:25 handsome_pirate: okay, we can probably do that at some point on the cloud sig list - it's easy enough to dole out access with IAM 17:35:28 * mattdm jumps in 17:36:07 not sure if this discussion needs to happen in go/no-go, though 17:36:08 so cloud community not testing and i386 img borket 17:36:25 rbergeron: assuming red hat has a close partnership with Amazon it should be free for us ;) 17:36:32 tflink: well, if it's blocker, we should cover it here 17:36:46 Viking-Ice: depends on if sandro counts as cloud or qa, i suppose 17:36:47 both? 17:36:57 but that doesn't matter much 17:37:04 tflink, both 17:37:16 but one indvidual is well one indvidual 17:37:18 mattdm: as Viking-Ice said, i386 ami is broken, also we would like to see more involvement from cloud people to test the stuff 17:37:27 rbergeron: Roger 17:37:36 mattdm: See what rbergeron just said 17:37:52 tflink: what's the problem with filling bug? 17:38:01 i don't know where to file it 17:38:04 yes. i've been swamped this week. 17:38:27 the i386 problem is permissions/releng, right? 17:38:29 mattdm: any idea where/how to report it? 17:38:50 mattdm: permissions were fixed. i have no idea what's wrong with it, though 17:39:11 mattdm: could you take a look and let us know then? 17:39:20 system log i grabbed before terminating: http://paste.fedoraproject.org/39105/13790023/ 17:39:55 maybe wrong aki? 17:40:41 mattdm: doubtful 17:40:43 we are getting to close to details now -> #fedora-qa or -devel pls just I'd want to be sure we will handle it correctly, not to forgot about it 17:40:44 i'll look into it. as for the bigger problem of where to track these.... 17:40:47 kernel issue? 17:41:04 Viking-Ice: or snafu with build process 17:41:06 anything else important missing in test matrices? 17:41:37 not really - RC2 didn't get much PXE but that didn't change much from RC1 and I'm not too worried about it 17:41:57 tflink: kparal was waiting for RC2 sync to run PXE test 17:42:15 ok, so let's move on 17:42:24 the arm desktop testing has been a bit sparse due to lack of widely dispursed HW but it is getting done 17:42:35 so I'm not so worried about that 17:42:36 either 17:42:39 tflink: yep, I asked arm guys to take a look 17:42:50 pschindl: any other concerns you see? 17:43:03 see/have 17:43:17 nothing from me. 17:43:24 (for initial-setup bug, we have working patch, just fyi) 17:43:37 ok, let's move on 17:44:15 #info issues - cloud coverage and broken i386 ami 17:44:25 #info arm coverage being worked on 17:44:39 #info PXE missing for RC2 but should be same as RC1 17:44:48 #topic Go/No-Go decision 17:45:08 ok, so QA already stated they are No-Go 17:45:09 QA is no-go due to open, unresolved blockers 17:45:26 #info QA is no-go due to open, unresolved blockers 17:46:10 now, do we want full week slip now or try it in less time? 17:46:27 jreznik: i really dont like not doing a full week 17:46:29 full week 17:46:37 we have the "no full week" feature 17:46:41 so lets use it for once 17:46:50 instead of adding an artifical delay 17:46:52 dgilmore: why? 17:46:54 drago01: we already used it once 17:47:07 yeah full week 17:47:29 so qa and releng in for a week 17:47:40 but I can see the point of having full week - RC validation was rushed as there was not much time (and kudos QA for the coverage in just half day!) 17:47:51 drago01: because everything in the releng world revolves around being scheduled as we normally do. if we dont do a full week it means a lot of extra work for me 17:48:05 as is i worked till 4am to get RC2 out last night 17:48:11 and I don't relish the idea of more days where I'm up until 6am 17:48:15 jreznik, we really should not be doing that it's better to just slip and give people enough time 17:48:37 rather then chasing some pointless release date 17:48:39 slipped product is better than slipped humans :) 17:48:47 Viking-Ice: yep, this time I'm for full week slip and thanks dgilmore for working on RC2! 17:48:56 +1 for full week 17:49:17 dgilmore: the extra work part makes no sense to me but ok 17:49:24 More time for another testing will be better. 17:49:40 proposed #agreed Fedora 20 Alpha is No-Go; to slip full one week 17:49:41 drago01: things that i do over days i have to cram into smaller time frames 17:49:55 dgilmore: ok 17:50:19 drago01: He is not lazy one, dgilmore is really worked hard to get RC2 done. 17:50:32 let's try to cover cloud better in that's week time 17:50:34 pschindl: I didn't say (nor imply) that 17:50:38 drago01: if we would have another RC in progress and we would just need some validation, I'd be for retrying it tomorrow, but there really wasn't as much testing as anyone would like to see for Alpha 17:50:55 so acks? 17:50:57 drago01: I thought so :) 17:51:01 ack 17:51:03 ack 17:51:03 * dgilmore acks a week 17:51:03 ack 17:51:07 ack 17:51:10 * nirik nods. 17:51:11 pschindl: it was more of a "hmm isn't this just kicking off some script" 17:51:51 * tflink is amused that most of the acks are qa folks :) 17:51:56 ack 17:51:59 anyway 17:51:59 ack 17:52:07 * jreznik can ack my own proposal :) 17:52:10 ack 17:52:28 #agreed Fedora 20 Alpha is No-Go; to slip full one week 17:53:14 ok, thanks for coming! I think it does not look bad for the next week, good job guys! 17:53:20 :) 17:53:33 question 17:53:37 (a bit of optimism is needed) 17:53:40 jwb: go on 17:53:41 jreznik: sure 17:53:52 does that 1 week slip cause everything else to slip out by 1 week? 17:53:57 jwb: yep 17:53:58 jwb: yes. 17:54:00 jwb: yes 17:54:15 hm 17:54:31 (that's why I wanted to avoid it if possible) 17:54:36 so final change deadline is 2013-11-19? 17:54:49 jwb: not ideal but we still have some buffer before christmas and we already did go/no-go on thanksgiving day 17:54:50 jreznik: yeah, I don't things are horrible - just a few things we found late. I'd be surprised if we didn't go next week 17:54:51 jwb: basically if we keep slipping we'll be in january. 17:54:52 jwb: Aye 17:54:55 or we'll be in mental hospitals. 17:54:56 :) 17:55:03 if we don't. 17:55:03 Oh, god 17:55:12 Visions of F18 come back 17:55:15 handsome_pirate: yep. 17:55:23 handsome_pirate: it's not that bad 17:55:25 I don't expect F20 to be as bad 17:55:28 ok. kernel team has some more thinking to do now 17:55:37 for what ? 17:55:39 jwb: what kind? 17:55:51 to determine if getting 3.12 into F20 is feasible 17:56:00 jwb: when is 3.12? 17:56:15 likely to be final around the first week of Nov 17:56:24 already close to -rc1 17:56:57 jwb: any big changes expected? 17:57:13 no more than every other rebase we push out to a stable release. 17:57:52 I say just go ahead and plan for it per tradition we probably slip again 17:57:53 ;) 17:58:15 +1 17:58:28 Viking-Ice: planning to fail? 17:58:36 jwb: seems doable in that time (if it will be released early nov) 17:58:46 tflink, no just sticking to tradition 17:58:57 of course, f20 has impacts to ARM. and ARM is... unstable. 17:59:02 so who knows 17:59:03 Viking-Ice: F19 tradition :) 17:59:08 like i said, thinking to do 17:59:30 There should be rule: "Every even release has to be slipped at least 4 weeks." :) 17:59:41 (that would be very nice tradition - one slip at alpha and then go, go) 17:59:51 pschindl: -1 million 18:00:01 jwb: ok, just let us know (so we can be prepared for it) 18:00:02 jreznik: im likely going home for november 18:00:25 or just really change the release cycle to something that more accurately reflects what we are doing 18:00:29 dgilmore: yeah, you told me already - how much online you would be? 18:00:47 jreznik: normal amount. just different hours 18:00:56 though ill likely take 1 or 2 weeks off 18:01:02 Viking-Ice: we will see how fedora.next will end up - open to everything 18:01:38 dgilmore: ok, let me know once you know better so we can see where we are 18:02:02 anything else to add? one hours passed and I need dinner before readiness meeting :) 18:02:11 heh 18:02:17 * handsome_pirate is good 18:02:45 so readiness meeting in one hour - see you later! 18:02:50 setting fuse 18:02:53 3... 18:03:14 * pschindl is cutting fuse to 2 18:03:33 * handsome_pirate lights it right next to the dynamite 18:03:37 BOOM! 18:03:44 thanks again! 18:03:49 #endmeeting