16:00:07 #startmeeting F23 Final Go/No-Go meeting #2 16:00:07 Meeting started Thu Oct 29 16:00:07 2015 UTC. The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:15 #meetingname F23-Final-Go_No_Go-meeting_2 16:00:15 The meeting name has been set to 'f23-final-go_no_go-meeting_2' 16:00:25 #topic Roll Call 16:00:28 morning everyone 16:00:31 Hi there 16:00:37 who do we have ? 16:00:42 .hello jkurik 16:00:43 jkurik: jkurik 'Jan Kurik' 16:00:58 * kparal is here if needed 16:01:21 roshi, dgilmore - are you with us ? 16:01:31 kparal: thanks 16:01:47 .hello sgallagh 16:01:48 sgallagh: sgallagh 'Stephen Gallagher' 16:01:48 Hello 16:01:49 * kparal pokes adamw 16:01:54 I am :) 16:02:02 * satellit listening 16:02:53 * pwhalen is here 16:03:38 pbrobinson: can you please represent release-engineering in case dgilmore is not present ? 16:04:02 * mattdm is here 16:04:16 jkurik: I can, but I'm not 100% up on where dgilmore is on primary 16:04:49 pbrobinson: better something then nothing :) 16:05:04 ok, lets start 16:05:42 #chair sgallagh kparal pbrobinson dgilmore mattdm nirik roshi 16:05:42 Current chairs: dgilmore jkurik kparal mattdm nirik pbrobinson roshi sgallagh 16:05:48 jkurik: I am here 16:06:06 dgilmore: great 16:06:20 #topic Purpose of this meeting 16:06:22 #info Purpose of this meeting is to see whether or not F23 Final is ready for shipment, according to the release criteria. 16:06:23 #info This is determined in a few ways: 16:06:25 #info No remaining blocker bugs 16:06:26 #info Release candidate compose is available 16:06:28 #info Test matrices for Final are fully completed 16:06:29 #link https://qa.fedoraproject.org/blockerbugs/milestone/23/final/buglist 16:06:31 #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC7_Installation 16:06:32 #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC7_Base 16:06:34 #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC7_Desktop 16:06:35 #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC7_Server 16:06:37 #link https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_RC7_Cloud 16:06:38 #topic Current status 16:06:43 #info We have several accepted blockers for the Final and also several proposed blockers for the Final. 16:06:50 #info Let's start with Mini-blocker review 16:07:02 roshi: may I ask for your service, please ? 16:07:07 sure thing 16:07:12 #topic Mini blocker review 16:07:21 3 proposed blockers, 5 accepted 16:07:24 first up 16:07:29 #topic (1276333) Anaconda crashes upon probing iSCSI LUN with existing LVM structures 16:07:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=1276333 16:07:35 #info Proposed Blocker, anaconda, NEW 16:07:40 * nirik reads 16:08:40 yeah, -1, very corner case... 16:08:55 -1 16:09:01 -1 16:09:09 /me was -1 in the BZ, here as well 16:09:12 -1 16:09:13 but good to have found and nice that it's fixed in rawhide already. ;) 16:09:19 yeah -1 16:09:32 -1 blocker +1 FE, +1 common bugs 16:09:43 dgilmore: I don't think this is a common bug either 16:09:43 yeah, as sgallagh mentioned - it is an edge case: -1 for blocker 16:09:58 aside from dgilmore - any other FE votes? 16:10:00 sgallagh: you apparently misunderstand what common bugs is 16:10:04 an uncommon bug? ;) 16:10:07 sgallagh: or I do 16:10:17 or is it sufficiently edge case to just reject and move on 16:10:20 +1 FE 16:10:21 sgallagh: its where we document know issues and workarounds 16:10:27 And I'm -1 FE simply because I don't want to see any non-mandatory churn in blivet at this point. 16:10:43 sgallagh: thats a poor reason 16:10:49 roshi: I do not see any benefit to have this as FE 16:10:58 at this point, neither do I 16:11:00 dgilmore: Not really; late changes to blivet often cause additional respins 16:11:12 -1 FE, too risky at this point 16:11:33 you can not take where we are in teh cycle as a consideration 16:11:37 * nirik guesses he could be +1FE, but would argue to not take it, so it's as good as -1 16:11:38 The point of the FE process is to determine risk of including things. 16:11:47 things are either blockers or freeze exceptions or not 16:11:49 proposed #agreed - 1276333 - RejectedBlocker Final - This bug is too much of an edge case to block release. 16:11:51 dgilmore: Not for blockers, sure. But for FE we absolutely can 16:11:54 ack 16:11:59 ack 16:11:59 ack 16:12:06 #agreed - 1276333 - RejectedBlocker Final - This bug is too much of an edge case to block release. 16:12:09 ack 16:12:15 #topic (1275770) Adding third monitor with i915 crashes Gnome 16:12:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=1275770 16:12:15 #info Proposed Blocker, xorg-x11-server-utils, NEW 16:12:36 sgallagh: FE we do not have to actually pull in 16:13:07 -1 blocker, +1 FE, I think it's a corner case we can fix in updates. 16:13:21 -1/+1 as well 16:13:30 -1 blocker 16:13:35 my thoughts as well 16:13:38 I voted -1/+1 in the BZ 16:13:41 -1 blocker, +1 FE 16:13:44 as "basic functionality" works fine 16:13:50 -1 blocker as it is just for a specific card and more then usual number of monitors :) 16:14:14 well, we see issues on many intel cards 16:14:21 but still, it's quite uncommon to have 3 monitors 16:14:40 and as a workaround you could use 2 until it's fixed. ;) 16:14:49 :) 16:14:50 and I guess the fix would not arrive that soon 16:15:21 proposed #agreed - 1275770 - RejectedBlocker AcceptedFreezeException Final - This bug doesn't quite violate the criterion as written, because "basic functionality" is still met. However, if there's a fix, we'd consider it in the event of another compose." 16:15:29 ack 16:15:39 ack 16:15:41 ack 16:15:49 ack - but there will not be "another compose" 16:15:49 ack 16:15:57 jkurik: Well... 16:15:59 #agreed - 1275770 - RejectedBlocker AcceptedFreezeException Final - This bug doesn't quite violate the criterion as written, because "basic functionality" is still met. However, if there's a fix, we'd consider it in the event of another compose." 16:16:02 ack 16:16:09 jkurik: let's hope so 16:16:14 #topic (1276226) yelp 3.17.3+ cannot open file locations, shows error message 'URL cannot be shown' 16:16:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=1276226 16:16:20 #info Proposed Blocker, yelp, NEW 16:16:24 So, this sucks. A lot. 16:16:46 Effectively, this results in the install media having no help dialogs. 16:17:03 yeah 16:17:28 yep. bummer. 16:17:37 No help for you! 16:17:48 google it :) 16:17:55 pbrobinson: +1 ;) 16:18:31 anyhow, this is unfortunate, but I don't feel we should block on it. -1/+1 16:18:33 Obviously no one needs help in Anaconda because it's simple and straightforward. 16:18:43 intuitive! 16:18:46 ahoy 16:18:50 god, why is it so early\ 16:18:54 sgallagh: yeah, who reads documentation :) 16:19:02 * nirik hands adamw some coffee 16:19:07 it sucks, but I also incline to -1/+1 16:19:15 -1 blocker, +1 FE 16:19:16 i honestly think this is pretty terrible 16:19:27 but i can be -1 because a) we never wrote a criterion and b) it's not a straightforward fix 16:19:28 same here 16:19:37 apparently none of us reads documentation... or we would have noticed sooner. ;) 16:19:46 I don;t like being -1, actually 16:19:50 for this bug 16:19:55 but still, if you think about it for a bit...it's the first thing most people see. and if they're having a problem, we're already losing their perception. and then they click Help and they get an error message? 16:19:59 it's pretty amateur hour. 16:20:13 agreed 16:20:14 Rookie question: What prevents you from downgrading to the working yelp? 16:20:16 s/pretty// 16:20:18 adamw: yeah 16:20:20 (no insult intended, just trying to emphasize it's a bad problem) 16:20:36 bradfirj: it'd be feasible, but we'd have to check it didn't break any *other* usage of it 16:20:41 Understood 16:20:48 yelp is the help system for GNOME, so 16:21:06 +1 FE 16:21:13 Reading BZ it looks like it's totally broken, even outside of anaconda 16:21:14 I'm clearly +1 FE here. 16:21:32 +1 FE for sure 16:21:36 I will take adamw's word it does not violate criteria 16:21:37 bradfirj: Right, but outside of anaconda, it can be fixed in an update 16:21:46 bradfirj: the style where it's invoked on a file path isn't used by everything 16:21:53 I'm also all for adding critera and tests for next time. ;) 16:21:53 If it will be FE - how we are going to fix it ? Downgrade ? 16:21:54 afaict most GNOME apps use a different style which still works 16:22:06 jkurik: we will not fix it 16:22:10 jkurik: making it FE basically means we're not going to fix it, unless another blocker showed up which i'm not aware of. 16:22:12 and I really want to be +1 blocker, since it's such a user facing thing, and will really frustrate people who needed it 16:22:18 jkurik: I spoke to the GNOME folks; a fix is being worked on, but I'm unsure of the timeframe 16:22:23 because if there are no blockers, we're shipping, most likely. 16:22:24 jkurik: but if we spin another RC we can pull in a fix 16:22:30 if there is one 16:22:37 ok 16:22:50 roshi: yeah, I'm kinda sympathetic to that view. sadly. 16:22:50 then +1 FE 16:22:58 yeah, i'm kinda with roshi. but we didn't catch it till yesterday and we don't have a criterion we can point to. 16:23:11 so i can be -1 very reluctantly, i guess, if we don't want to slip another week to try and fix it. 16:23:13 I am with roshi also 16:23:21 I think we have a quorum of FESCo around if we're prepared to declare it a FESCo-level blocker 16:23:27 but we can only go by what the guidelines say 16:23:49 unless FESCo decided to block on it 16:23:49 * nirik doesn't think we should block on it. 16:23:56 dgilmore: we *can* write a new criterion on the fly. viking_ice used to hate us changing the rules on the run like that, and i kinda do too, but we've done it before, where we felt something 'obviously' should be a blocker 16:24:02 eh. the guidelines are guidelines. there are plenty of things that could be even more terrible but aren't in the guidelines 16:24:14 yeah, it's not a blocker per the criterion (though, I'll be proposing such a criterion) 16:24:19 (for F24) 16:24:20 Yeah, I'm more open to adding a new blocker than dropping one at Go/No-Go, but I don't much care for either 16:24:25 adamw: sure. it is a path I do not like 16:24:42 * adamw would be interested in what #anaconda folks think 16:24:43 let me ask 'em 16:24:48 "Fedora Project: Making things up as we go since 2003!" 16:24:53 the thing is... I would be ok blocking on it if we had a critera and tested for it... but this is kind of last minute... 16:25:07 Honestly, I'm torn here because it *is* a pretty visible problem that you're likely to hit when trying to solve other problems. 16:25:20 But at the same time, it isn't preventing the system from working in any meaningful way. 16:25:24 yeah, if it's going to block F23, I'd want FESCo to do it 16:25:30 and propose a new criterion for F24 16:25:33 And it's not the bad-old-days where Google didn't yet exist 16:25:42 It seems like the kind of thing reviews might notice and comment on 16:25:49 for sure 16:25:57 I dunno if that's more or less important than being annoying to users :) 16:26:03 "Need Help? Fedora has none for you!" 16:26:17 mattdm: yeah "headline" fear 16:26:21 roshi: +1 XD 16:26:22 * roshi can see the headlines :p 16:26:44 Nobody tell TheRegister, I can see the headlines too 16:26:58 * nirik notes that they will read this and _now_ they will note it. ;) 16:27:00 Nobody do #info on this at least. 16:27:07 "Fedora knew the help was broken but went forward anyway" 16:27:11 :) 16:27:12 I know some of the reporters read the minutes :) 16:27:24 no worries. Default to open! 16:27:41 so, votes on getting FESCo to vote on this being a blocker? 16:27:43 * adamw notes that phoronix is probably reading this. hi, phoronix. :P 16:27:55 let's have a vote on the vote! 16:27:59 On the other hand, we actually got pretty good press on the slip we just had, with most people being happy we were holding for quality. 16:28:07 we need to form a comittee to vote on voting 16:28:07 I'd lean towards no. 16:28:32 #info Fedora ♥s reporters! 16:28:41 Anyway, I'm going to vote -1 blocker here, but not happily. 16:28:47 hey phoronix, we're just gonna, uh, leave this $500 here in the corner, alright? 16:28:51 and mattdm doesn't have chair ... ;p 16:28:54 .fire mattdm for using unicode icons 16:28:54 adamw fires mattdm for using unicode icons 16:29:04 it'd be terrible if the wrong person were to pick it up. just awful. 16:29:15 #info Fedora ♥s reporters! 16:29:20 dgilmore++ 16:29:37 /me can't fire dgilmore, he's too valuable. 16:29:38 #chair mattdm 16:29:38 Current chairs: dgilmore jkurik kparal mattdm nirik pbrobinson roshi sgallagh 16:30:08 anyhow, where are we on votes? 16:30:14 +1 to let FESCo decide 16:30:19 i'm sticking with sadface -1/+1. 16:30:19 I haven't seen a single +1 blocker vote 16:30:34 I'm still -1/+1 also 16:30:36 though i don't object to asking fesco. 16:30:55 sgallagh: it does not violate criteria, so the only way its a blocker is if FESCo says so 16:31:07 Right 16:31:22 -1/+1, and FESCo opinion :P 16:31:30 I thought we had more of FESCo here, but it looks like only three of us. 16:31:39 I'm not sure we can scare up all of fesco on short notice. 16:31:47 especially those in .eu 16:31:51 right 16:31:59 * adamw lights up the fesco beacon 16:32:00 if we can get a fix this morning for yelp, I can make RC10 and we can test it and ship Tuesday 16:32:05 proposed #agreed - 1276226 - RejectedBlocker AcceptedFreezeException Final - As regrettable as this is, it doesn't actually violate any criterion and is not blocking. However, FESCo will be discussing this as it's a nasty user facing bug. 16:32:07 Straw poll from the three people here? 16:32:32 OK, yeah let's just fire up the FESCo-signal^H mailing list and ask 16:32:33 sgallagh: I think all 3 of us are -1 blocker 16:32:37 ack 16:32:40 ack 16:32:42 ack 16:32:42 ack 16:32:54 ack 16:32:55 sgallagh: its not going to effect me but i would be willing to fix if we get it quick enough 16:32:56 #agreed - 1276226 - RejectedBlocker AcceptedFreezeException Final - As regrettable as this is, it doesn't actually violate any criterion and is not blocking. However, FESCo will be discussing this as it's a nasty user facing bug. 16:33:02 dgilmore: I'll check on it. 16:34:15 Checking with the GNOME folks now; cschalle will get back to me soon with an ETA 16:34:38 okay 16:34:51 sgallagh: it's worth asking about brad's suggestion (can we just drop to 3.16.0) 16:35:25 * mattdm is afk to meet wife for lunch. see you all in a bit 16:35:59 ok, thats all proposed? do we want to go over the accepted? 16:36:02 adamw: Added to the queue 16:36:22 nirik: they're all fine. 16:36:28 cool. 16:36:29 well, assuming someone checked the release notes are actually right in RC7. 16:36:41 oh 16:36:42 well 16:36:42 can you read those with yelp? ;) 16:36:43 adamw: RC9 that is underway now 16:36:47 dgilmore: wat. 16:36:51 i guess we need to discuss that one 16:36:58 #1276165 16:37:00 adamw: RC7 and 8 failed 16:37:02 yeah 16:37:04 dgilmore: awesome 16:37:12 adamw: yeah i am super happy 16:37:13 #topic (1276165) F22 release notes still in F23 16:37:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1276165 16:37:13 #info Accepted Blocker, fedora-release-notes, ON_QA 16:37:36 so, yeah, another one we somehow missed until now. 16:37:37 So this is the reverse of the previous one 16:37:42 * roshi imagines dgilmore green and saying "You won't like me when I'm happy." 16:37:51 A criterion exists, but maybe isn't useful any more :) 16:38:09 Jeepers, dgilmore is imposing enough *without* hulking out. 16:38:12 sgallagh: well, it could do with a bit of a tweak 16:38:24 but i'm OK with blocking on 'an image has the F22 release notes on it', really 16:38:28 this is another one I'd really rather not ship with 16:38:38 i'm fine with an image not having the release notes *at all* - i think workstation actually took 'em out 16:38:46 they did 16:38:48 This is the ONLY change between RC6 and RC9, correct? 16:38:54 but having the *wrong* release notes sitting there in the menus is just bad. 16:39:02 I am +1 to block on this 16:39:05 adamw: I am okay with making sure release notes are fixed, and doing a quick sanity test of RC9 16:39:06 Hold up 16:39:09 sgallagh: yeah, should be. well, that and anything they did in the compose process to try and fix Atomic. 16:39:12 It's not part of Workstation, so where is it? 16:39:17 sgallagh: KDE and Xfce at least 16:39:26 also DVD? 16:39:26 all the spins I think? 16:39:28 Oh FFS 16:39:28 possibly any of the other goddamn 5,000 images we build now 16:39:37 i didn't really have time to check all of 'em 16:39:56 I mean, if it was only on Server or something where no one would ever see it... 16:40:41 no, i found it while i was doing the KDE menus test. 16:40:45 it's also on cloud 16:40:48 and arm 16:40:53 somehow managed to avoid dying of terminal boredom before i got that far through the menus. 16:41:04 Why the is it on Cloud? 16:41:06 wouldnt this be an easy zero day fix 16:41:12 Southern_Gentlem: not for the live images. 16:41:27 it's in @standard 16:41:36 nirik: i thought cloud only took @core ? 16:41:54 anyhow, yeah: our thinking on this was, we can do a quick respin with the correct release notes and then just sanity check the results 16:42:02 # Packages to enable server images to run in cloud environments 16:42:02 ...@standard 16:42:05 all RC6 testing would be valid for it since this was the only change 16:42:11 Right 16:42:13 so we accepted it quickly to get RC7 (or, well, RC9) spun. 16:42:23 expecting that the sanity testing could be done overnight, only the compose failed. 16:43:02 * nirik nods 16:43:07 so if we really, really wanted to just ship RC6, we'd have to agree to ditch the release criterion, basically. 16:43:24 otherwise we can go ahead and test RC9 today and ship it, i guess, or we can slip. 16:43:26 should we just keep this meeting open to do that? or how much 'sanity testing' should we leave for go? 16:43:30 wrong release notes, no help 16:43:39 it's intuitive! 16:43:43 adamw: What about the "Reconvene tomorrow with RC10 hopefully including the yelp fix" option? 16:43:52 * nirik is +1 blocker here and thinks we should test RC9 16:44:29 nirik: +1 16:44:42 I am okay waiting until tomorrow to make the decision 16:44:48 well, it's already an accepted blocker 16:44:49 nirik: +1 16:45:14 I like the RC10 idea 16:46:14 if we get a yelp fix, I lean heavily for waiting for that 16:46:34 roshi: RC9 is underway 16:46:45 RC10 we could do if we get a yelp fix 16:47:10 welp, I guess that's it for the blocker review portion 16:47:37 roshi: thanks 16:47:52 * roshi would want an RC10 just for that fix - guess we'll just wait for what FESCo says 16:48:14 np jkurik, glad to help 16:48:19 +1 roshi 16:48:29 so, sounds like we should have one more Go/No-Go meeting tomorrow, right ? 16:48:30 Update on the yelp situation 16:48:35 Good news/bad news 16:48:44 sure, always is 16:48:49 Bad news: a fix for this will not happen within 24 hours. 16:49:24 Good news: We *could* try to get a fast anaconda build that calls yelp with the URI format instead of the file path format 16:49:32 If they are willing to do so 16:49:45 or, just back out that version to a knownworking one 16:49:55 would that work? 16:50:01 thats what epochs are for 16:50:02 anaconda's files aren't in the right place and are in a different format. 16:50:11 i meant the URI thing, not the downgrade thing. 16:50:18 adamw: sure :) 16:50:18 +1 for blocking on this. Wait for RC9+ and let the OpenQA do basic testing and then release it. 16:51:00 adamw: Unclear; I'm asking the anaconda folks now 16:51:14 roshi: As for the downgrade, mclasen__ didn't seem confident that it would be safe 16:51:23 k 16:51:28 ah 16:52:16 you are asking us to build a 3.16 yelp against 3.18 gtk, newer webkitgtk, ... 16:52:41 that seems to have a lot more unknowns and potential to break help for all apps 16:52:46 mclasen__: it was a thought 16:52:48 mclasen__: Agreed 16:52:53 I would wait for RC9 just becouse of the amount of work dgilmore left on it. 16:53:09 * roshi wasn't sure what all was involved, it was just a thought mclasen__ 16:53:16 I'm looking at some possible workarounds here 16:53:32 yelp comes with a yelp-build script that you can run to generate html from the docbook 16:54:45 nirik: to go back to the earlier question, btw, for 'sanity testing', the openQA tests plus a decent subset of 'burn the thing to actual media and check it boots properly' tests would be ok, i think. 16:55:23 adamw: :) 16:55:29 ok. sounds like people would just prefer to meet again tomorrow same time and decide if RC9 was go or not 16:55:45 seems like it 16:55:52 Sounds good to me 16:56:12 * nirik was just trying to figure a way to just say 'rc9 is go if no blockers found by xyz time' so we could stage sooner, etc. 16:56:17 * roshi will cover some of the burning to media tests and get some cloud folks to test the cloud stuff 16:56:20 if someone comes up with a decent-looking fix for the help issue we can do RC10, I guess. 16:56:43 nirik: we can probably have it done by this evening, i'd guess. 16:57:05 but it'd be *good* to have the brno folks' testing time on it too. 16:57:32 adamw: they could test all day tonmorrow :) 16:57:41 * kparal is excited 16:57:56 time to break from the isolation unit 16:57:56 dgilmore: well, if we do the decision tomorrow, yes. if we aim to do it tonight (US time), they can't. 16:58:01 don't worry, kparal will find something else :p 16:58:05 * adamw bangs some more nails in 16:58:30 adamw: Is it an isolation unit or an iron maiden? 16:59:13 adamw: quick... change his /etc/hosts to point to partner-bugzilla.redhat.com for bugzilla.redhat.com. ;) 17:01:50 sgallagh: potato, potahto 17:02:05 #info RC9 to be built to accomodate BZ 1276165 17:02:50 so, voting about meeting tomorrow at the same time or waiting till RC9 is build and then decide ? 17:03:03 lets just meet again tomorrow same time 17:03:09 that will allow more testing time 17:03:51 FWIW, it's looking increasingly unlikely that a fix for the anaconda help issue will land today. 17:04:28 ok, then lets meet tomorrow 17:05:26 #info Go/No-Go decision to be made on Friday's meeting which is going to be organized at the same time as today 17:05:54 anyone wants to go through coverage matrices ? 17:06:20 looks like we do not need to do this now 17:08:07 #topic Go/No-Go decision 17:08:55 No-Go today, revisit tomorrow 17:09:06 #agreed We are going to organize one more Go/No-Go meeting on Friday to make the final decision as we need to have RC9 ready before the decision is made 17:09:15 #topic Open floor 17:09:28 so, thanks for the meeting folks 17:09:40 anything else someone want to discuss ? 17:09:49 Thanks everyone 17:10:23 thanks for running things jkurik 17:10:37 #action jkurik to plan the Friday's Go/No-Go meeting 17:11:12 * jkurik is going to close the meeting in approx. 60s 17:11:33 thanks jkurik 17:11:44 thanks jkurik 17:11:52 ... 30s ... 17:12:20 thanks all for comming 17:12:24 #endmeeting