17:00:27 #startmeeting F29 Final Go/No-Go meeting 17:00:27 Meeting started Thu Oct 18 17:00:27 2018 UTC. 17:00:27 This meeting is logged and archived in a public location. 17:00:27 The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:27 The meeting name has been set to 'f29_final_go/no-go_meeting' 17:00:28 #meetingname F29-Final-Go_No_Go-meeting 17:00:28 The meeting name has been set to 'f29-final-go_no_go-meeting' 17:00:29 \o/ 17:00:31 Let's party! 17:00:37 #topic Roll Call 17:00:37 .hello2 17:00:38 frantisekz: frantisekz 'František Zatloukal' 17:00:39 .hello psabata 17:00:42 contyk: psabata 'Petr Šabata' 17:00:43 .hello nphilipp 17:00:45 nils: nphilipp 'Nils Philippsen' 17:00:47 .hello ngompa 17:00:48 Pharaoh_Atem: ngompa 'Neal Gompa' 17:00:51 .hello2 17:00:52 coremodule: coremodule 'Geoffrey Marr' 17:01:20 .hello mkonecny 17:01:21 mkonecny: Sorry, but you don't exist 17:01:30 .hello2 17:01:31 dmoluguw: dmoluguw 'Dinesh Prasanth Moluguwan Krishnamoorthy' 17:02:13 .hello2 17:02:14 sgallagh: sgallagh 'Stephen Gallagher' 17:02:18 .hello mohanboddu 17:02:19 mboddu: mohanboddu 'Mohan Boddu' 17:03:05 i think we have enough to get started here 17:03:19 #topic Purpose of this meeting 17:03:20 #info Purpose of this meeting is to check whether or not F29 Final is ready for shipment, according to the release criteria. 17:03:25 #info This is determined in a few ways: 17:03:27 #info 1. No remaining blocker bugs 17:03:32 #info 2. Release candidate compose is available 17:03:33 #info 3. Test matrices for Beta are fully completed 17:03:45 bcotton, are you going to run the blocker review? 17:03:52 coremodule: unless you want to 17:04:04 but before we get to that point 17:04:24 i haven't seen announcement of an RC compose. is one available? 17:04:35 no, nothing 17:04:36 no 17:04:47 bcotton: Nope, we are still working out on blocker bugs 17:04:50 so, i think that make it pretty clear what the decision will be 17:04:51 RC composes will start emerging once we solve all the blockers 17:05:10 go, obviously. ;P 17:05:11 morning 17:05:18 the question is now do we want to run a blocker review meeting now, or handle it in the regular monday meeting? 17:05:21 .hello2 17:05:22 bowlofeggs: bowlofeggs 'Randy Barlow' 17:05:30 * nirik thinks it might be good to run now. 17:05:31 bcotton: We should run the blocker review 17:05:37 .hello2 17:05:41 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 17:05:42 bcotton, lets run a mini one now for the 4 proposed and we can review the others on monday 17:05:42 bcotton: Generally we will use this time for blocker review 17:05:50 Ideally we want to have an RC by Monday to have enough time for testing 17:05:57 worksforme 17:06:01 Waiting until then to decide blockers is tantamount to deciding to slip another week 17:06:12 #topic Blocker review 17:06:16 coremodule: will you lead the blocker bug meeting or should I handle it? 17:06:21 #info 4 Proposed Blockers 17:06:23 #info 7 Accepted Blockers 17:06:31 frantisekz, if bcotton doesn't want to lead it, I will go ahead and do it 17:06:41 let's look at the proposed blockers 17:06:46 oh, I forgot bcotton can run it... sorry :) 17:06:51 coremodule: i'll do it and you can jump in to correct me when i do it wrong ;-) 17:06:53 :) 17:06:54 #chair coremodule 17:06:54 Current chairs: bcotton coremodule 17:07:01 #topic (1640235) Unprivileged use of dnf list installed ends with a unhandled exception 17:07:03 haha, you got this! 17:07:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=1640235 17:07:04 #info Proposed Blocker, dnf, MODIFIED 17:07:15 -1 blocker, +1 FE 17:07:23 it doesn't break any criteria 17:07:42 I voted -1 blocker, +1 FE in the BZ 17:08:00 also, this happens only with dnf 4, which is not in F29 yet 17:08:10 -1 blocker, +1 FE, looks like the fix is already available as well as what frantisekz said ^ 17:08:20 -1b/+1fe 17:08:23 -1, +1 FE from me too 17:08:40 -1, +1 from me as well 17:08:41 frantisekz: right ,but it will be most likely as it fixes a blocker 17:08:51 I propossed that bug not per the bug itself, but for the fact that dnf sent a major update version to fix some blocker and FE and we elevated the case to fesco on monday 17:08:52 I'd vote +1 blocker, just because its basic functionality 17:08:58 yeah, there is a fesco ticket, if we should pull the dnf 4 17:09:13 jlanda: it's not actually a major version update 17:09:14 here the big thing will be what fesco decides about dnf 4 during freezing 17:09:23 but shortly, there are blockers in dnf 3 and dnf team does not have time/resources to backport fixes into dnf 3 17:09:43 jlanda: It's not *actually* a major version update, but it does include a bunch of changes that aren't strictly blocker/FE bugs, which is not ideal 17:09:56 We'll probably end up waving it through like we did with GNOME at Beta, though 17:09:58 but, dnf 4 should be counted as 3.7 17:10:00 nirik: nor it's a just bug fixing update as this bug has evidence it 17:10:07 they just synced versioning with yum 17:10:13 zbyszek: i'd argue non-privleged use of dnf isn't basic functionality, but i get your point 17:10:15 right 17:10:39 -1 Blocker +fe 17:10:40 anyhow -1 blocker, +1 FE... 17:11:00 okay, seems like we have a strong consensus 17:11:16 zbyszek: Feel like dying on this hill, or is FE satisfactory? 17:11:37 no, plenty of other hills in sight ;) 17:11:55 FE is good enough, and the whole point is moot since it seems we'll pull the update in anyway 17:12:01 proposed #agreed 1640235 - RejectedBlocker AcceptedFreezeException (Final) This does not violate release criteria, but should be fixed if dnf 4 is included in F29 17:12:07 ack 17:12:09 ack 17:12:13 ack 17:12:15 ack 17:12:16 ack 17:12:18 ack 17:12:20 ack 17:12:21 ack 17:12:31 ack 17:12:35 #agreed 1640235 - RejectedBlocker AcceptedFreezeException (Final) This does not violate release criteria, but should be fixed if dnf 4 is included in F29 17:12:42 (not sure if I count but anyway) 17:12:43 ack 17:13:01 #topic (1640626) Google Chrome repository silently disabled when upgrading to F29 17:13:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=1640626 17:13:03 nils: If you showed up, you count 17:13:04 #info Proposed Blocker, fedora-workstation-repositories, ON_QA 17:13:21 gotcha 17:13:28 -1blocker +1 CB 17:13:29 This was accepted as an FE earlier in the day, but I realized it is *probably* a blocker as well 17:13:37 #info 1640626 is accepted as a FreezeException 17:13:38 Southern_Gentlem: CB? 17:13:40 sgallagh and I think this bug is a potentially good candidate for a 0day blocker 17:13:47 common bug 17:13:52 .hello2 17:13:53 bhavin192: bhavin192 'Bhavin Gandhi' 17:13:56 coremodule: Right, that's effectively what I was proposing 17:14:03 we don't need to vote for CBs imo 17:14:06 Southern_Gentlem: I think it's going to hit a sizable number of our users 17:14:23 I should note that it's not limited to Chrome, that was just where I discovered it 17:14:30 * nirik reads 17:14:38 It affects ALL of the third-party software shipped in those repos 17:14:41 and that is a tiny fix o reenable the repo 17:14:53 The chrome is used by plenty of users, so this should be blocker 17:14:55 anyway, I feel it should be a blocker 17:14:55 I'm not sure how many people it would affect tho 17:14:59 If you had Steam or PyCharm installed as well, it would break 17:15:20 Steam could be installed from flatpak 17:15:21 sgallagh, does it block the upgrade 17:15:26 does gnome-software actually enable those when you install from them? I know it searches them when disabled. 17:15:33 bcotton, side note: I will secretarialize for the meeting if there are no qualms from you 17:15:41 coremodule: thank you! 17:15:47 bcotton, no problem! :) 17:15:48 Southern_Gentlem: No, it means that after the upgrade, you no longer get updates for Chome (including security updates) 17:16:00 until you enable the repo 17:16:02 i'm +1 since it's potentially dangerous 17:16:02 If you aren't specifically aware of this, you're not going to know to enable it manually 17:16:18 +1 blocker i mean 17:16:19 nirik: It does 17:16:20 makes sense to mark as a common bug, but why did this happen? 17:16:33 +1 blocker 17:16:46 common bug doesn't make sense if it gets accepted as an blocker 17:16:48 Pharaoh_Atem: Whoever wrote the fedora-workstation-repositories package installed the repo files without %config(noreplace) 17:16:52 So they clobber any local changes 17:16:53 +1 blocker 17:17:07 +1 blocker 17:17:13 I suppose +1 blocker, it would be pretty bad... 17:17:35 Anyway, the fix is ready. I just think that if it turns out I made a mistake, it's serious enough that it's worth blocking to correct it. 17:17:55 Or rather 0day blocking 17:17:56 uh, +1 blocker 17:17:59 not that bad imho but not a hill i want to die on either 17:18:02 +1 blocker 17:18:22 sgallagh: when upgrading from the old package (without %config(noreplace)) to the new one (with it), does the old content get preserved? 17:18:35 Or does the %config(noreplace) only work going forward? 17:18:36 ^ I didn't think of that 17:18:58 should get an .rpmsave if it's marked %config 17:18:59 #proposed agreed 1640626 - AcceptedBlocker (Final) - This would silently disable third-party repos shipped in the fedora-workstation-repositories package, preventing upgrades and security patches to thoes packages. 17:19:00 +1 blocker since if people dont know what happened, then probably they wont get any updates esp security updates 17:19:01 AIUI 17:19:09 ack 17:19:11 ack 17:19:12 ack 17:19:13 nils: I *think* the new package would see that it differs and not replace it. 17:19:21 ack 17:19:22 I'm going to test it exhaustively 17:19:24 ack 17:19:31 uhm no it doesn't 17:19:33 Should just get a .rpmnew next to it 17:19:36 (apart from my misplaced #) 17:19:41 nils: argh, what? 17:19:41 ack 17:19:52 ack 17:19:55 sgallagh, I only have the new repo file from the pkg here 17:19:57 ack 17:20:03 #agreed 1640626 - AcceptedBlocker (Final) - This would silently disable third-party repos shipped in the fedora-workstation-repositories package, preventing upgrades and security patches to thoes packages. 17:20:04 ack 17:20:16 #topic (1633133) [abrt] gjs: gtk_box_pack(): gjs-console killed by SIGSEGV 17:20:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=1633133 17:20:19 #info Proposed Blocker, gjs, NEW 17:20:20 nils: I will do some further testing. 17:20:25 If it's not complete, I'll offer new updates. 17:20:35 That's why I wanted the blocker decision... 17:20:41 this should be probably re-asigned to gnome-maps 17:20:50 as it is the only app it triggers the crash 17:21:03 Workstation WG is going to vote on Monday about whether to stop shipping Maps in the default install 17:21:16 #info Workstation WG is going to vote on Monday about whether to stop shipping Maps in the default install 17:21:16 this is very similar to 17:21:18 I think this is a dupe of the other one we already approved. 17:21:22 .bug 1637751 17:21:23 coremodule: Bug 1637751 – Display gets messed up when routing panel is active - https://bugzilla.redhat.com/1637751 17:21:26 and as such (if this gets accepted), we'll have 2 blockers for gnome-maps 17:21:51 do these repos expand the Fedora release version in the link or will people stick with f28 repos until they update their configs? 17:22:39 so, I guess the question here is if the thing that causes it to crash is 'basic functionality' 17:22:45 i'm +1 if f29 ships with gnome maps, and +1 FE if it doesn't 17:22:54 :D 17:23:16 as of this moment, f29 will ship with gnome maps 17:23:25 I am +1 b here, not that I would want gnome-maps out of default install, but... 17:23:35 +1 blocker 17:23:50 mostly because we've already decided this is a blocker in 1637751 17:24:09 +1 blocker for the same reason ^ 17:24:10 +1 17:24:24 +1 blocker 17:24:31 +1 blocker 17:24:47 +1 17:24:48 so this is when you click on it? or ? 17:25:15 nirik: you open routing, then right click somewhere and then click on "what's here" 17:25:22 contyk: there's no version embedded in the file, so it's "updated automatically" 17:25:35 +1 blocker 17:25:45 +1 blocker 17:25:58 proposed #agreed 1633133 - AcceptedBlocker (Final) - the issues mentioned in the bug are widely reproducible and agreed to violate "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test". We note that dropping the app from Workstation is acceptable if a fix is 17:26:00 not available 17:26:04 ack 17:26:04 I can't get it to do that here in rawhide, but ok... blocker I suppose. 17:26:12 ack 17:26:14 ack 17:26:25 ack 17:26:25 i'll cut a few characters out to get it fit on one line, apparently 17:26:31 ack, even though I can't reproduce it 17:27:30 #agreed 1633133 - AcceptedBlocker (Final) - the issues mentioned in the bug are widely reproducible and violate "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test". We note that dropping the app from Workstation is acceptable if a fix is not available 17:27:43 thanks for the wording, adamw :-) 17:28:04 #topic (1640701) GNOME Software "update and restart" button appears to do nothing 17:28:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1640701 17:28:07 #info Proposed Blocker, gnome-software, NEW 17:28:44 that sounds terrible, too bad We didn't catch this one earlier 17:29:10 +1 B 17:29:18 +1 blocker 17:29:18 yeah, +1 blocker 17:29:18 +1b for sure 17:29:21 kalev confirmed that this is an issue and is working on it 17:29:40 +1 blocker 17:29:52 +1 17:29:55 hold on 17:30:06 wait, why would this matter for GA vs an FE? 17:30:07 holding on 17:30:17 +1 17:30:20 all basic apps must work crit 17:30:27 Pharaoh_Atem: See the criterion I cited in the BZ 17:30:29 oh right, duh 17:30:34 +1 Blocker 17:30:41 +1 blocker 17:30:43 * Pharaoh_Atem was waiting for bz to load :) 17:30:54 More specifically, the Beta one about the graphical default package manager needing to work 17:31:04 right, right 17:31:11 While it *does* work, it takes so long that any reasonable person would assume it's hung 17:31:12 yeah, so then I agree on its blocker-ness 17:31:21 proposed #agreed 1640701 - AcceptedBlocker (Final) - Violates: The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops 17:31:21 +1 Blocker 17:31:22 it's not borked, just... slow 17:31:26 ack 17:31:27 ack 17:31:29 ack 17:31:30 ack 17:31:31 ack 17:31:33 ack 17:31:40 ack 17:31:47 ack 17:31:48 ack 17:31:59 #agreed 1640701 - AcceptedBlocker (Final) - Violates: The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops 17:32:17 okay, that's the end of proposed blockers 17:32:25 welp 17:32:33 #topic Current status 17:32:58 #info 11 open blockers (including 4 accepted in this meeting) 17:33:12 #info No RC compose is available 17:33:31 sounds like a No-Go then? 17:33:39 anything else we want to enter as current status before we put the official decision down? 17:33:51 bcotton: I'd like to hear the state of testing 17:34:06 sgallagh, bcotton sure, standby while I gather the results. 17:34:08 Most of the blockers are concentrated in specific areas; how's our testing outside that? 17:34:09 it would be super awesome to get a rc before the weekend, but not sure how practical that is. 17:34:11 standing by 17:34:25 what I'm a bit concerned about is how did we not notice the gnome-software issue 17:34:39 it's a matter of waiting a while, sure, but shouldn't this have come up before? 17:34:39 nirik: for sure no 17:34:48 we need to wait for fesco and workstation wg 17:34:50 meetings 17:34:52 iirc, openqa should be able to catch these things? 17:35:12 Pharaoh_Atem, so openqa should install third party repos? 17:35:35 if we support them (and we technically do by offering them), yes 17:35:39 frantisekz: why fesco? also there could be a maps update fixing those issues... I think rishi said he might try and fix them 17:35:40 Southern_Gentlem: I think he means the other one, though. 17:35:51 The one where there's no progress notification and it looks like it hung 17:35:52 but yeah, I meant the g-s not doing anything one 17:36:01 nirik: I was thinking about decision whether to pull dnf 4 17:36:12 there is a fesco ticket for it 17:36:42 yes, I know. we can (and should) vote in ticket tho... so it might be decided soon. 17:37:04 sgallagh: maybe I'm misunderstanding how our auto-tests work, but wouldn't we be able to tell from that? 17:37:23 Pharaoh_Atem: Yes, but I suspect this specific case isn't covered. 17:37:35 Probably they just have it wait until after a reboot then check the results. 17:37:50 testcase coverage is generally good, all the cloud/atomic test cases could use a test since the latest release, but as the last tests passes, we should be able to pull over the results if need be. I don't think we need to though, because of the obvious outcome of this meeting; we have time. 17:38:07 view the testcase coverage here: https://www.happyassassin.net/testcase_stats/29/ 17:38:19 #info testcase coverage is generally good, all the cloud/atomic test cases could use a test since the latest release 17:38:26 #link https://www.happyassassin.net/testcase_stats/29/ 17:38:45 any questions or comments on testing? 17:39:09 I didn't know this actually existed 17:39:27 shouldn't we have this somewhere more prominent on an fp.o website? 17:39:31 I think the openqa test is just a) faster and b) waiting 17:39:47 nothing special here! adamw is away, so bear with the QA team as 5 work together to do the job of 1 ;P 17:39:59 coremodule++ 17:39:59 bcotton: Karma for coremodule changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:40:02 Pharaoh_Atem: We (Fedora QA) are working on something to make all our tools/sites more visible to the public 17:40:09 coremodule++ 17:40:09 Conan_Kudo: Karma for coremodule changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:40:11 frantisekz++ 17:40:12 Conan_Kudo: Karma for frantisekz changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:40:44 https://openqa.fedoraproject.org/tests/297997 is one I think... took ~4min there. 17:41:39 okay, well let's make this official i guess 17:41:53 #topic Go/No-Go decision 17:42:06 normally, i'd poll FESCo, RelEng, and QA individually 17:42:11 but i think it's pretty clear 17:42:25 so raise your hand if you object to a No-Go decision 17:42:34 No RC, No-Go 17:42:52 Accepted Blockers, No-Go 17:42:54 ^ 17:43:04 pretty clear. no-go 17:43:04 #agreed Fedora 29 Final is NO-GO 17:43:09 i object to the No-GO but that is life :) 17:43:11 #info The next F29 Final Go/No-Go meeting will be Thursday, 2018-10-25 at 1700 UTC 17:43:21 Go.... to the bar 17:43:25 (No Go) 17:43:26 #action bcotton to announce decision 17:43:37 #action bcotton to update schedule 17:43:51 #topic Open floor 17:43:52 Anything else we need to discuss before closing? 17:43:57 alas, we couldn't repeat the awesomeness of F28 release 17:44:04 but hopefully we won't slip again :) 17:44:10 Note for phoronix readers: This is not a slip, it's just using the second of our possible release dates. Completely fine. 17:44:12 we can still make the second target date 17:44:14 Pharaoh_Atem, :) 17:44:17 ;) 17:44:19 nirik++ 17:44:26 nirik++ 17:44:26 Conan_Kudo: Karma for kevin changed to 35 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:44:27 Nothing to see here. Move along. 17:44:31 nirik++ 17:44:31 frantisekz: Karma for kevin changed to 36 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:44:31 nirik++ 17:44:34 nirik++ 17:44:36 nirik++ 17:44:37 nils: Karma for kevin changed to 37 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:44:45 so many cookies for nirik 17:44:46 nirik++ 17:44:46 Southern_Gentlem: Karma for kevin changed to 38 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:44:53 * nirik likes cookies. 17:44:55 bcotton++ 17:45:01 nirik++ 17:45:01 bhavin192: Karma for kevin changed to 39 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:45:16 bcotton: I think we've given you all the cookies already :P 17:45:20 okay, last call before i close the meeting 17:45:25 nothing here! 17:45:31 nothing here 17:45:32 bcotton, thanks for leading the meeting! 17:45:33 * bhavin192 thinks nirik will share all the cookies :P 17:45:37 you're all welcome to join us back here in 75 minutes for the release readiness meeting 17:45:51 yes, thank you bcotton for hosting this 17:45:54 bhavin192, share what the cookies are gone 17:45:58 👍 17:46:02 👍 17:46:06 * bcotton bangs gavel 17:46:09 #endmeeting