17:00:31 #startmeeting F22 Alpha Go/No-Go meeting 17:00:31 Meeting started Thu Mar 5 17:00:31 2015 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:32 #meetingname F22 Alpha Go/No-Go meeting 17:00:32 The meeting name has been set to 'f22_alpha_go/no-go_meeting' 17:00:54 #topic Roll Call 17:00:59 * roshi is here 17:01:00 hey everyone! 17:01:04 morning 17:01:33 .hello sgallagh 17:01:34 sgallagh: sgallagh 'Stephen Gallagher' 17:02:02 .hello dmossor 17:02:03 danofsatx: dmossor 'Dan Mossor' 17:02:05 let's wait a moment for more people to join us 17:02:07 .hello mattdm 17:02:08 mattdm: mattdm 'Matthew Miller' 17:02:57 #chair roshi mattdm sgallagh nirik 17:02:57 Current chairs: jreznik mattdm nirik roshi sgallagh 17:03:28 * roshi sits down 17:03:46 stand up roshi! we have work to be done! 17:03:48 #topic Purpose of this meeting 17:03:51 * pwhalen is here 17:04:15 #info Purpose of this meeting is to see whether or not F22 Alpha is ready for shipment, according to the release criteria. 17:04:16 #info This is determined in a few ways: 17:04:18 #info No remaining blocker bugs 17:04:19 #info Release candidate compose is available 17:04:21 #info Test matrices for Alpha are fully completed 17:04:32 #link http://qa.fedoraproject.org/blockerbugs/milestone/22/alpha/buglist 17:04:34 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Alpha_TC8_Installation 17:04:35 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Alpha_TC8_Base 17:04:37 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Alpha_TC8_Desktop 17:04:38 #link https://fedoraproject.org/wiki/Test_Results:Fedora_22_Alpha_TC8_Server 17:04:51 #topic Current status 17:05:20 so, for current status, we don't have RC, one of the conditions for go/no-go meeting 17:05:42 but we don't look that bad today, if you take a look on blockers list 17:05:46 However, one is being currently filed. 17:06:06 thanks everyone for cleaning up blockers list but as sgallagh says, we have one blocker to be discussed 17:06:31 and I think it makes sense to start with it, before we get to any plans for alpha 17:07:14 The remaining blocker was split from a previously-accepted blocker bug when we realized there were two problems overshadowing one another 17:07:17 #info no RC available, one proposed blocker bug, otherwise accepted blockers seems to be in a good shape for testing 17:07:30 Both have been fixed as of NetworkManager-1.0.0-7.fc22 (I have validated it personally) 17:07:39 #topic Mini blocker review 17:08:06 sgallagh++ 17:08:09 roshi: do you want to do this part for QE or me? 17:08:16 sure thing 17:08:18 #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria 17:08:18 #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria 17:08:18 #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria 17:08:42 the one proposed blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1199098 17:09:07 I was prepared to ask for it to be just FE based on it apparently being only limited hardware, but pschindl was able to reproduce it on a desktop as well 17:09:18 He was going to update the BZ, but apparently hasn't gotten around to it. 17:09:19 :( 17:09:31 jreznik: Not to worry, it's already fixed :) 17:09:41 :) 17:09:43 And I'm told that the NM build that included it is already part of the RC1 request 17:09:55 So basically, approving this is for posterity. 17:09:57 it's a clear violation of the criteria 17:10:01 +1 17:10:26 +1 blocker 17:10:40 +1 17:10:46 yep. +1 blocker 17:10:56 proposed #agreed - 1199098 - AcceptedBlocker Alpha - This bug is a clear violation of the alpha criterion: "The installed system must be able to download and install updates with the default console package manager." 17:11:11 Ack 17:11:18 ack 17:11:42 #agreed - 1199098 - AcceptedBlocker Alpha - This bug is a clear violation of the alpha criterion: "The installed system must be able to download and install updates with the default console package manager." 17:11:54 * roshi loves it when a blocker is fixed before it's voted on :) 17:12:21 hehehe 17:12:26 great and thanks for help roshi! 17:12:34 (Special thanks to dcbw for his rapid turnaround) 17:12:41 sgallagh: +1 17:13:15 np, glad to be of service :) 17:13:31 for already accepted blockers, I don't see the need to go through as all are MODIFIED or ON_QA 17:13:40 or anything anyone? 17:13:53 * roshi has nothing concerning the blockers 17:14:04 best blocker meeting ever! 17:14:17 is there a badge for that? :p 17:14:39 mattdm: but not the best go/no-go meeting , at least now 17:14:41 #topic Test Matrices coverage 17:14:41 mattdm: certainly shortest during a Freeze 17:14:59 just a quick look on what QE coverage we have for latest TC 17:15:20 as it can help us with RC testing and decision what to do :) 17:16:04 https://fedoraproject.org/wiki/Test_Results:Fedora_22_Alpha_TC8_Summary 17:16:05 ahoyhoy 17:16:17 and of course https://www.happyassassin.net/testcase_stats/22/ 17:16:45 * roshi updates the cloud results 17:16:51 I'll be running through the full set of Server criteria as soon as RC1 is available 17:17:27 note, for alpha the 'generic netinst' test in default boot and install is a lie, the 'generic' media generation isn't hooked up yet 17:17:27 is there anything we should take a look before RC is ready that makes sense to test on TC8? 17:18:06 jreznik: Server was pretty completely blocked by the FreeIPA client and server issues. 17:18:13 note for the cloud: our old fedora private cloud is now too old to spin up any of the f22 qcow2 images. Dunno if that matters to others out there, but definitely something to note. 17:18:20 But RC1 will have fixes for those, so testing should go smoothly, I hope 17:18:29 cloud looks all good to go for alpha, had some issues with openstack, but that wasn't a image fault - and I have reports of it working fine on openstack at other places 17:19:03 will do more testing of RC1 when it lands 17:19:05 arm desktop testing is missing 17:19:08 #info server testing was blocked by FreeIPA client and server issues 17:19:20 adamw, its been updated for kde 17:19:30 kde was fairly busted in tc8 17:19:47 its working, albeit very slow 17:20:07 #info our old fedora private cloud is now too old to spin up any of the f22 qcow2 images 17:20:07 hum, testcase_stats might have a bug there...i'll look into that :P 17:20:25 (it's the compat=1.1 in the images, so you need qemu > 1.1 to use them) 17:20:25 i just did as well, might be some lag in updating/ 17:20:58 pwhalen: that's actually a good question what desktop we want for ARM now as KDE is now on Plasma 5 - so it needs OpenGL for desktop and thus the same as for GNOME Shell 17:21:47 #info cloud looks all good to go for alpha, had some issues with openstack, but that wasn't a image fault 17:21:49 * ajax chuckles 17:22:23 does Plasma need opengl even with desktop effects disabled? 17:22:26 #info ARM KDE is covered but very slow 17:22:28 adamw: yes 17:22:31 jreznik, ive always thought xfce(as it was). kde and gnome work, just want to shoot yourself as you wait 17:22:32 hum 17:22:45 adamw: it's QML2 based 17:22:53 pwhalen: the only problem with xfce is it's never been a release-blocking desktop, so we'd effectively add another of those 17:23:02 anyhow, we can discuss it out of the meeting 17:23:06 yep 17:23:07 adamw, i think thats why you guys decided kde 17:23:22 anyhow it works. 17:23:25 I just wanted to point it out as pwhalen was talking about slowness there 17:23:45 #topic Go/No-Go decision 17:24:15 well, we are pretty clearly no go right now. ;) 17:24:17 it's pretty clear, where we are now but what can we do to unblock Alpha? or slip? 17:24:29 i think we could do an alpha testing run on rc1 by tomorrow if that helps 17:24:35 as alpha testing is not *huge* and we have coconut to help 17:24:35 but the question as it always is: slip a week, or try and do heroics and see if we can sign off tomorrow.. 17:24:49 that's one option, it depends if people are willing to do it 17:25:01 dgilmore I think is against that in the past as it doesnt' allow for staging/mirroring time? 17:25:14 * jreznik is ok with heroic effort and help as much as possible 17:25:26 but yeah, it's also question for rel-eng 17:25:46 I am not a fan of it 17:25:57 as it will cut down time for mirrors to get content 17:26:23 well, it's alpha - so there's probably not that need to have it everywhere at alpha release 17:26:33 for GA, it's different story 17:26:37 it is probably less important 17:26:37 what percentage of mirrors host alpha content? 17:26:44 roshi: most 17:26:44 * roshi is just curious 17:27:01 ah 17:27:06 though i do not know we make exact numbers 17:28:18 dgilmore: when do you think rc1 compose ends? 17:28:18 If we slip a week for Alpha, is there any possibility to make that up in Beta to stay on GA schedule, pursuant to FESCo desire to be date-driven? 17:28:27 jreznik: im just starting it now 17:28:32 jreznik: so about 9 hours 17:28:47 stickster: usually we call that "lying to ourselves" 17:28:50 stickster: it's possible but really something we should not do unless we have real reason 17:28:50 stickster: none 17:28:53 * roshi is fine with doing testing tonight 17:29:12 I'll be testing Server RC1 tonight. 17:29:16 *nod. I just want to make sure we explicitly cover that in discussion. 17:29:19 well, we can always try for a tomorrow sign of, and if it blows up, slip 17:29:39 if people are up for it, that sounds awesome. 17:29:40 * roshi will handle cloud and can hammer on some i386 install testing as well 17:29:44 yeah, that's what we're talking now about 17:29:47 nirik: +1. If we're "close enough to taste it," *and* everyone is agreed it's worth the effort. 17:30:08 stickster: we're now trying to agree on that 17:30:17 i'll be testing too, and the brno folks will be able to test through their working day tomorrow. 17:30:35 i think rc1 has an okay shot, as long as no-one lets kparal near it 17:30:48 i hear kparal is on vacation :) 17:30:51 or other option fesco allowed some time ago is wednesday release, so it will add one more day for mirroring 17:30:57 mattdm: a vacation he couldn't refuse 17:31:04 adamw: nice 17:31:06 adamw: :))) 17:31:45 jreznik: that doesnt help a lot 17:31:59 jreznik: unless I do the staging on saturday 17:32:27 we would need to inform the mirrors beforehand 17:32:37 as some people manually sync the releases tree 17:32:38 dgilmore: I think it's now really up to you, we don't want to force rel-eng to something you don't think is good for release 17:33:01 dgilmore: What time on Friday do you normally sync the mirrors? 17:33:07 sgallagh: in the morning 17:33:14 usually 9am Central 17:33:35 dgilmore: Is the Friday time adjustable? Can it happen 2 hours later? 17:33:48 Or is that back to "notify the mirrors" territory? 17:33:50 we would probably have a good unofficial indicator of rc1 go-ness by that time i'd guess 17:33:55 the insight into mirroring is very fuzzy. the mirrors lists are essentially dead 17:34:11 sgallagh: I honestly do not know 17:34:18 ok 17:34:19 mirrors are completely disenggaged 17:34:27 I announce it and things happen 17:34:30 adamw: yep, it's almost one day here in Brno 17:34:43 in the past there was a lot of chatter anc communication as mirros got lined up 17:34:48 now it is just quiet 17:35:03 I think thats partly to do with everyone having more BW and such. 17:35:10 nirik: maybe 17:35:23 the last few releases even our master mirrors have been fine. Long ago they would get swamped completely. 17:35:28 so can we try to get RC out, try testing and do a quick check of status at 10 am and we will see where we are? 17:35:30 nirik: It seems like we were much busier around releases in general in the past, too. Mostly because we're better at it now IMHO. 17:35:31 we have a ton more BW now 17:35:38 stickster: yeah, that too. 17:35:38 It just makes it difficult to judge and know if we would be okay putting it on late friday or saturday 17:36:05 I would think an announcement would be sufficient -- and if there *is* a problem, better for it to happen at Alpha than at GA. It's a good way to test the waters. 17:36:14 dgilmore: well, two more hours for example would not be that bad I'd say 17:36:21 jreznik++ 17:36:27 I can't speak for anyone else, but I'm prepared to pull an all-nighter if we want to have a Go/No-Go meeting at 9:30 Central tomorrow. 17:36:45 same here 17:36:48 jreznik: My concern was whether the mirrors had automation that would be missed. 17:36:58 And therefore they'd need to be told to adjust 17:36:59 although, I might be passed out by 930 central tomorrow :p 17:37:00 sgallagh: we don't know. ;) 17:37:08 Right 17:37:21 I know kernel.org is using fedmsg trigger now. Which is excellent. 17:37:28 indeed 17:37:40 (ie, they only sync when they see we updated updates or other content) 17:37:45 nirik: except we do not use fedmsg for releases 17:37:55 dgilmore: right, that doesn't help for those (yet anyhow) 17:38:13 sgallagh: its really unknown 17:38:14 anyhow, that all doesn't need to be discussed here. ;) 17:38:28 so, I am +1 for meeting again tomorrow morning at the same time to see if we can go. 17:38:30 and we're not in circle :) 17:38:30 dgilmore: Right, hence why I recommended reconvening at 930 central. 17:38:50 sgallagh: 9:30 is ? utc? 17:38:52 So we'd have time to approve and release to mirrors before 10:00 central 17:39:16 930 central is two hours ago 17:39:23 (right?) 17:39:30 sgallagh: correct 17:39:47 16UTC? 17:39:52 well, 16:30 17:39:52 jreznik: 1530 UTC 17:40:26 0930 CST = 1030 EST = 1530 UTC (note this calculation changes over the weekend because DST starts in USA) 17:40:27 yep, I got it - just my worldtimebuddy was already 4 locations 17:41:16 maybe we can do 8:30 am, so 9 am will be possible? 17:42:12 8 am will be 3 pm here so I'd say most of the testing should be pretty much covered by that time and I don't expect many folks to spend friday afternoon testing 17:43:29 8:30 am central/14:30 utc? 17:43:52 * adamw won't make that most likely, but y'all don't need me :) 17:44:10 * stickster has to slip afk for a few... but once we schedule a time, would be good to have #info + #action (+ person) for everything 17:44:37 adamw: yeah, I know but I expect at that time it would be clear if we are at least blocked 17:44:43 #action sgallagh to test Fedora Server RC1 Alpha validation tonight 17:44:49 being up at that hour after an all nighter is a long shot for me, but I can try to be here for another go/no-go after testing 17:44:50 jreznik: yep 17:44:51 someone just has to take a look on qa coverage 17:45:08 stickster: sure, as always (you know that person) 17:46:05 adamw, roshi: well, we don't want to overcommit here... and we will definitely need some QA here tomorrow, I hope someone from Brno can cover 17:46:34 fair enough :) 17:46:53 let's try proposal :) 17:47:40 it's easy enough to see the coverage, just look at the summary page and check all the Alpha entries 17:47:43 except the usual suspects like SAS 17:48:02 proposal #agreed to try second Go/No-Go Friday 2015-03-06 8:30 am central/14:30 utc 17:48:14 or patch 17:48:45 proposal #agreed Fedora 22 Alpha is No-Go as of 2015-03-04, we agreed to try second Go/No-Go Friday 2015-03-06 8:30 am central/14:30 utc 17:48:51 +1, ack 17:49:13 adamw, nirik, dgilmore, sgallagh... 17:49:20 +1, ack 17:49:41 sure 17:49:51 +1 17:50:20 +1 17:50:30 +1 from me for record 17:50:42 #agreed Fedora 22 Alpha is No-Go as of 2015-03-04, we agreed to try second Go/No-Go Friday 2015-03-06 8:30 am central/14:30 utc 17:50:57 ok, thanks everyone! 17:51:25 #action jreznik to announce decision on devel-announce 17:51:40 thanks jreznik 17:52:04 I can try early morning coordination here in Brno but I expect all nighters will be still online :) 17:52:17 #topic Open floor 17:53:12 * roshi has nothing 17:53:13 reminder - the Alpha readiness meeting is in one hour, the same channel 17:53:42 setting fuse for 3... 17:54:07 dgilmore: What's the estimate on RC1 delivery? 17:54:26 /me may try to nap the afternoon away ;-) 17:54:54 sgallagh: as i said earlier about 9 hours 17:54:56 * jreznik will setup very early alarm for tomorrow :) 17:55:01 I missed that. Thanks 17:55:05 sgallagh: earlier was 10 minutes or so 17:55:12 its only just started 17:55:13 about 3:00 UTC, by my estimation 17:55:28 hey there 17:55:44 #info RC1 compose already started, expected delivery is 3:00 UTC 17:56:41 2... 17:57:18 1... 17:57:25 thanks for coming! 17:57:31 #endmeeting