17:00:48 #startmeeting F25-Final-Go/No-Go-meeting 17:00:48 Meeting started Thu Nov 17 17:00:48 2016 UTC. The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:48 The meeting name has been set to 'f25-final-go/no-go-meeting' 17:00:58 #meetingtopic F25 Final Go/No-Go meeting #2 17:01:07 #topic Roll Call 17:01:10 .hello sgallagh 17:01:13 sgallagh: sgallagh 'Stephen Gallagher' 17:01:14 .hello fale 17:01:14 .hello jkurik 17:01:16 fale: fale 'Fabio Alessandro Locati' 17:01:19 jkurik: jkurik 'Jan Kurik' 17:01:51 * satellit listening 17:02:02 adamw, nirik, mboddu, dgilmore: are you around for the Go/No-Go meeting ? 17:02:28 hols 17:02:32 hola 17:03:28 ok, so we have a representant of FESCo and RelEng. We need someone from QE .... 17:04:51 Hi! 17:04:52 adamw: tflink: around? 17:04:57 .fas lailah 17:04:58 Kohane: lailah 'Sylvia Sánchez' 17:05:03 morning 17:05:08 hi all 17:05:36 Hi everybody. Lets start with formalities and hopefully adamw will appear 17:06:04 #chair dgilmore mattdm sgallagh adamw 17:06:04 Current chairs: adamw dgilmore jkurik mattdm sgallagh 17:06:21 #topic Purpose of this meeting 17:06:22 #info Purpose of this meeting is to check whether or not F25 Final is ready for shipment, according to the release criteria. 17:06:41 #info This is determined in a few ways: 17:06:43 #info No remaining blocker bugs 17:06:44 #info Test matrices are fully completed 17:06:46 #info Final RC compose is available 17:06:59 #topic Current status 17:07:01 #info The F25 Final RC is available: 17:07:02 #link https://pagure.io/releng/issue/135 17:07:04 #link http://dl.fedoraproject.org/pub/alt/stage/25_RC-1.3/ 17:07:07 #info Test results for F25 Final are available: 17:07:22 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Summary 17:07:24 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Installation 17:07:25 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Base 17:07:27 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Server 17:07:28 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Cloud 17:07:30 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Desktop 17:07:31 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Security_Lab 17:07:32 .hello bowlofeggs 17:07:33 bowlofeggs: bowlofeggs 'Randy Barlow' 17:07:54 There are still some blockers 17:07:56 #info We have 3 accepted blockers and 1 proposed blockers 17:07:57 #link https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist 17:08:56 Time for mini-blocker-review? 17:09:01 adamw: now we really need you :) 17:09:52 I can chair the mini blocker review, however without someone from QE we will not be able to make decisions I am afraid 17:10:28 jkurik: Does the process actually state that? I thought it was just "consensus of the persons present" 17:10:33 There is a bankholiday day in CZ/Brno so even QE team from Brno is not available 17:11:23 /me would like to believe that the set of people attending the Go/No-Go meeting would provide a reasonable cross-section of views. 17:12:17 adamw was around a bit ago... 17:12:25 sgallagh: I am not sure. Reading https://fedoraproject.org/wiki/Go_No_Go_Meeting gives me no explicit answer to this 17:12:32 .hello adamwill 17:12:33 adamw: adamwill 'Adam Williamson' 17:12:46 why do I never know when this meeting is 17:12:55 wow, we are ready to go now :) 17:13:07 thanks adamw for comming 17:13:14 jkurik: My reading of that is that if there are unresolved blockers, the QA team's vote is automatically "block" 17:13:30 adamw: may I ask you please to lead the mini-blocker review ? 17:14:28 'meeting outcomes' states " Release is unanimously declared GOLD by a representative from Development, Release Engineering, and Quality Assurance." 17:14:44 (though it doesn't actually seem to allow for any *other* outcome, which makes me wonder what we're doing here at all :>) 17:14:48 sure 17:14:52 #topic Mini-Blocker Review 17:14:52 did you chair me? 17:14:56 /me opens the champaign 17:14:57 yes, I did 17:14:59 roger 17:15:07 err, champagne. Wow, spelling fail. 17:15:33 champagne spelling: whiskey ? 17:15:40 hehe 17:15:51 so we have one proposed blocker to review and one accepted that got re-opened to re-consider 17:15:51 LOL 17:16:02 here's the proposed blocker: 17:16:03 #topic (1394937) Running processes killed (SIGKILL) without a chance to shut down cleanly (SIGTERM) on logout or shutdown 17:16:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=1394937 17:16:03 #info Proposed Blocker, systemd, NEW 17:16:21 so, I filed this, but there's still quite a bit of confusion due to insufficient investigation, i apologize for that 17:17:00 based on what I know: -1 blocked +1 FE, we can (and should) fix in an update... 17:17:11 I'm really on the fence with this one, because on the one hand, there's a slight chance of data loss, but on the other hand, this has been the behavior throughout the whole cycle and no one *noticed* any data loss. 17:17:11 s/blocked/blocker/ sheesh 17:17:20 And it's something that *can* be fixed post-release. 17:17:22 it's difficult to really pin down any clear-cut case here aside from http://bugzilla.redhat.com/show_bug.cgi?id=1366897 , which we already discussed and rejected 17:17:27 yes, -1 to block and +1 to FE (perhaps 0day ?) 17:17:42 i'm somewhat concerned by Bojan's case, but it doesn't seem clear enough to block on that alone. 17:18:04 I saw this behaviour long ago and I don't remember losing any data. 17:18:19 It was just annoying but not harmful. In my laptop at least. 17:18:24 Kohane: Well, data-loss would be sort of a race-condition. 17:18:47 It's possible that a process that is in the middle of writing data out to disk could be interrupted in the middle by the logout. 17:18:49 jkurik: since we don't precisely even know what's broken yet, a 0-day fix seems unlikely :) 17:18:55 But that's likely to be rare, since logout is a human action. 17:18:57 it sounds like it also happens in f23/f24... or perhaps just f24 too... 17:19:04 we do have the https://bugzilla.redhat.com/show_bug.cgi?id=1366897 case that's fairly clear, it would be nice if someone could sit on the desktop team for that one. 17:19:04 it was probably caused by an update (as it is present in F23 and F24 as well), so it can be fixed by an update as well 17:19:06 (Meaning, you probably don't log out while you still have tasks running) 17:19:34 It doesn't happen to me in Workstation F24 17:19:34 -1 block +1 FE since we have it already in current release 17:19:59 jkurik: agree 17:20:14 Kohane: gnome desktop? wayland or no? 17:20:25 proposed #agreed 1394937 - it's still not entirely clear what (if anything) is broken here besides #1366897, which we already discussed and rejected as a blocker. we do not see anything else clear enough to constitute a blocker here 17:20:26 Gnome desktop, not Wayland 17:20:34 Maybe is it related to Wayland? 17:20:40 ack 17:20:41 Kohane: the GNOME case is, we know that. 17:20:49 ack 17:20:53 the question is whether there's anything else going on here, which doesn't seem to be at all clear 17:22:11 ack/nack/patch? 17:22:25 considering 17:22:37 ack 17:22:47 ack 17:22:57 ack 17:23:25 stickster: you representin' the desktop team here? See adam's comment above re https://bugzilla.redhat.com/show_bug.cgi?id=1366897 17:23:47 he did vote in bug... 17:24:11 i think that was more the 'sit on them' comment. 17:24:20 #agreed 1394937 - it's still not entirely clear what (if anything) is broken here besides #1366897, which we already discussed and rejected as a blocker. we do not see anything else clear enough to constitute a blocker here 17:24:22 ah, ok. 17:24:31 okay, so, moving onto the accepted blocker that was re-opened 17:24:42 #topic (1390607) LibreOffice Impress (and stripped down native gtk demo) doesn't run presentation correctly on Wayland 17:24:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1390607 17:24:43 #info Accepted Blocker, mutter, ASSIGNED 17:27:03 I agree with stickster https://bugzilla.redhat.com/show_bug.cgi?id=1390607#c38 . -1 to block on this, +1 FE 17:27:46 I think there's more going on here than just presentation mode, because on reading this more carefully, I've seen similar stuff happening with just regular windows being auto-placed in locations where it's impossible to reach their title bars. 17:27:47 yeah, so it sounds like the base issue was fixed, but there is another corner case that can cause it to fail. 17:28:41 since it's possible to deliver a presentation (with mirroring) I'm for -1 block, +1 FE 17:28:49 i think at this point we can probably document sufficient workarounds for the 'running a presentation from the live image' case, and fix it better with an update 17:28:58 so i think i'm -1 now 17:29:01 Yeah, I'm -1 to blocking at this point, since there are reasonable workarounds. 17:29:07 yeah, -1 blocker 17:29:14 -1 blocker 17:29:18 (By "reasonable" I mean, "most people could figure out to switch to mirroring") 17:30:46 proposed #agreed 1390607 - RejectedBlocker - while it's unfortunate that this isn't fully fixed, we think the current state is good enough for release (we can document workarounds for the remaining broken cases), and we can fix it fully with an update 17:30:55 ack 17:30:57 ack 17:31:00 ack 17:31:14 ack 17:31:37 ack 17:32:39 #agreed 1390607 - RejectedBlocker - while it's unfortunate that this isn't fully fixed, we think the current state is good enough for release (we can document workarounds for the remaining broken cases), and we can fix it fully with an update 17:33:29 adamw: I guess that is all, right ? 17:33:57 The remaining two blockers are VERIFIED and were present in RC 1.3, as I understand it. 17:34:10 yes, I think so 17:34:49 yep, that should be it 17:34:51 adamw++ 17:34:53 thanks 17:34:56 adamw++ 17:34:56 sgallagh: Karma for adamwill changed to 18 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:35:05 #topic Test Matrices coverage 17:35:06 adamw++ 17:35:07 #link https://fedoraproject.org/wiki/Test_Results:Fedora_25_RC_1.3_Summary 17:35:16 ...huh, how did we get that far without my having given you a cookie yet? 17:35:38 adamw++ 17:36:19 adamw++ 17:36:24 aww, stoppit 17:36:38 #info remaining accepted blockers have been verified fixed in RC-1.3 17:37:27 how you people see the test cases coverage ? 17:37:34 adamw: why stop? don't you like cookies? 17:38:48 Kohane: he's just being coy 17:39:27 is QA:Testcase_install_to_iSCSI_no_authentication mandatory on ARM ? 17:41:06 jkurik: not mandatory, it's there 17:41:41 than we have very strong coverage 17:41:51 is there anything I have overlooked ? 17:42:04 good ol' SAS 17:42:11 oh, unless tflink did it 17:42:28 the guy who has the actual SAS device and hit an actual bug with it didn't report back yet whether the fix we put in RC-1.3 is sufficient or there's another bug behind it 17:42:29 but, meh. 17:42:34 nope, i can start a new run, though 17:42:53 * adamw stuffs tflink into the kparal isolation device 17:42:55 nope. we're good. 17:43:04 :P 17:43:05 ok, either way 17:43:16 nah, seriously, go ahead if you like. yours worked with RC-1.2 though, right? 17:43:20 or 1.1 or whatever you tested 17:45:28 adamw: do you see this as potentionaly blocking issue ? should we wait for the tflink's result ? 17:45:44 yeah, 1.2 worked fine 17:45:55 jkurik: SAS is on the list of things that we may deprioritize in F26 anyway. I'm fine with trusting the 1.2 results. 17:46:01 ok, so lets move on then 17:46:27 proposed #info Test Matrices coverage for the Final release is pretty strong and sufficient 17:47:08 ack 17:47:16 ack 17:47:19 ack 17:47:33 #info Test Matrices coverage for the Final release is pretty strong and sufficient 17:47:37 #topic Go/No-Go decision 17:47:54 QE, FESCo, RelEng -> we need +1 17:48:05 +1 with my FESCo hat on 17:48:06 dgilmore, sgallagh, nirik, adamw ^^^ 17:48:19 +1 to go 17:48:32 +1 to go 17:48:41 for the record: I am +1 to GO 17:49:45 * stickster gets back from shop and +1's to go! 17:49:48 coverage is fine, no outstanding blockers, so QA votes go. 17:50:01 figurehead fpl vote +1! 17:50:06 adamw++ 17:50:10 #info The Fedora 25 Final compose 1.3 is considered as GOLD 17:50:10 /me opens another bottle of champagne 17:50:12 I missed the cookie party 17:50:14 * adamw patpats mattdm 17:50:16 * Kohane is not in QE/FESCo/RelEng but also +1 to go 17:50:18 #link http://dl.fedoraproject.org/pub/alt/stage/25_RC-1.3/ 17:50:22 stickster++ 17:50:22 sgallagh: Karma for pfrields changed to 19 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:50:24 aww, isn't he a cute lil' figurehead 17:50:36 #action jkurik to publish the Go/No-Go result 17:50:40 adamw++ 17:50:41 adamw: He needs that, he's now the "oldest" FPL and thus frequent comforting is required 17:50:54 Is that official at this point? 17:50:58 stickster: I thought it was frequent bourbon 17:50:59 sgallagh: yup 17:51:03 mattdm++ 17:51:03 sgallagh: Karma for mattdm changed to 8 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:51:04 as of last week I think? 17:51:10 dgilmore: what's the difference? 17:51:12 A record I'm happy to see broken 17:51:20 dgilmore: bourbon, comforting is all the same 17:51:42 #topic Open floor 17:51:45 frequent Southern Comfort 17:52:11 someone would discuss anything releated to purpose of this meeting ? 17:52:30 Actually, one question that I just thought of. 17:52:44 adamw: Did the upgrade from F23 question ever get sorted out? 17:53:35 For context: there was an issue with GNOME Software distro-upgrades where it was unpredictable which version would be shown to a user if there were two possible upgrade targets. 17:53:43 adamw: I am sure there is some 17:54:16 sgallagh: no, it didn't. 17:54:37 OK, that's a bit concerning. 17:54:52 sgallagh: my suggested gameplan is we see what happens when the pkgdb collections json is updated and then claim strenuously that's precisely what we intended to happen. whatever it turns out to be. 17:54:57 * adamw has plausible justifications ready. 17:55:26 Is that JSON fixed for the life of the distro? 17:55:32 (Will it change when F26 arrives?) 17:55:36 i don't think it is theoretically, but i think it is practically. 17:55:44 * stickster notes that until we jump up to say two-release upgrades work well, they don't 17:55:50 dgilmore / puiterwijk / someone would probably know better. 17:56:03 stickster: we've been testing two-release upgrades for the last couple of cycles. 17:56:03 stickster: We've been saying that they do for a couple releases now 17:56:11 really? 17:56:13 23->25 is reasonably well tested, for default package cases at least. 17:56:26 /me tested several 22->24 upgrades as well 17:56:29 I must have missed that -- I knew some testing was happening but not that we said "supported" (for whatever that means for us) 17:56:35 stickster: https://openqa.fedoraproject.org/tests/48901 17:57:08 Hmm, it's like this open source stuff is a moving target ;-P 17:57:10 stickster: it's written into the release criteria since ~22. what we really need to clear up next is what we actually tell people to do in the instructions. 17:57:16 stickster: Yeah, we consider that "official" at this point 17:57:18 which i'm supposed to be starting a thread about. 17:58:02 I did 18 to 25 I do not recomend it 17:58:12 That was... bold 17:58:20 dgilmore: wuss. i did 13->25 while i was updating the 'upgrading with dnf' instructions. 17:58:32 lol 17:58:34 real testers do it with /usr move and grub2 migration 17:58:42 adamw: :P 17:58:50 adamw: I've said many times you have real testers 17:58:55 :P 17:59:11 * stickster wins this meeting, mic drops 17:59:32 OK, but back on track: we should probably make a group decision about how to handle that JSON situation. I don't *love* adamw's answer, but I can live with it. 18:00:03 sgallagh: if we really want to achieve a specific outcome, we can try and make koji (or whatever it is that produces that JSON) produce a specific order. 18:00:31 Right, so there are three possible choices: 18:00:32 1) Take whatever we get at random and justify it ex post facto 18:00:42 2) Assert that we always want upgrades to be single-version 18:00:47 adamw: I thought that depending on the encoding/decoding lib JSON ordering wasn't settable... wouldn't a change to g-s be a better option? 18:00:53 3) Assert that upgrades should always go to the most recent stable version 18:01:17 stickster: yes, it is, but twiddling the json output is easier. you *can* achieve specifically ordered json, it's just a bit of work. 18:01:19 (assuming that's required, I'm flying blind here) 18:01:59 stickster: I vote #3 18:02:10 I mean, sgallagh :) 18:02:13 If we take either 2) or 3), those would end up being "special blockers" (or whatever we're calling them now) 18:02:19 Yes, I think 18:02:24 #3 18:02:27 is better 18:02:33 People who want to go to an intermediate version can use the command line 18:02:44 I am #3 18:02:51 * nirik nods. seems reasonable 18:03:07 #3 seems reasonable to me too 18:03:19 OK, but that's half the question. The other half is: are we willing to slip for #3 if we had to? 18:03:46 /me doesn't know if kalev or hughsie would be able to fix this by Tuesday, if it needs GNOME Software changes. 18:03:54 sgallagh: NO 18:04:06 * stickster points out #3 is SHOULD, not MUST -- and would not want to see that be a blocking criterion (although "upgrades MUST work when they happen" seems reasonable) 18:04:09 sgallagh: NO WAY 18:04:26 I already tweeted about it. This is a done deal. 18:04:28 :) 18:04:34 heh. 18:04:36 adamw: what json? 18:04:38 stickster: You caught me. I used my least-favorite word in 2) and 3) 18:04:44 I meant to say "must" 18:04:54 the releases json on the pkgdb api 18:04:56 dgilmore: https://admin.fedoraproject.org/pkgdb/api/collections/ 18:04:56 i.e. if we release F26 and the only remaining blocker is "F25 shows up as upgrade instead of F26 for F24," I wouldn't block on that. 18:05:20 Neither I. 18:05:27 It's not a blocker. 18:05:38 adamw: pkgdb makes that inside of itself 18:05:48 dgilmore: once F25 goes stable, gnome-software in F23 will offer upgrade to *either* F24 or F25, depending on whether F25 comes above or below F24 in that list after it's changed to 'Active' status 18:06:05 whichever one comes last will be the one it offers 18:06:19 adamw: if its in the wrong order, we will have to file a pkgdb bug to fix it 18:06:54 (well, in a 'clean' case. i haven't actually looked into how aggressively it re-considers, if it's already noticed that F24 is available and you don't force it to refresh.) 18:07:45 well, as long as the "right" order is known. ;) 18:08:32 right, we don't actually know what we want yet. 18:08:56 i'm not sure we want to just make a hasty decision in this meeting. i was planning a devel@ thread. as this is really about the package maintainers 18:09:02 they're the ones who have to make sure the upgrade works 18:09:08 I think it's pretty clear that the folks in this meeting want it to be 3) above 18:09:14 (I agree, FWIW) 18:09:19 adamw: sensible. 18:09:38 in theory we're already requiring them to fix N+2 upgrade bugs, but still, it's worth a wider airing i think. 18:09:44 * stickster does think that fiddling JSON seems hackier than telling the software to "find the latest" 18:10:07 ideally that would be something settable by policy, too 18:10:13 "find next" vs. "find latest" 18:10:24 stickster: haha, configuration options in GNOME, are u serious 18:10:35 adamw: PackageKit.conf is a thing ;-) 18:10:51 settable by distro policy I mean 18:11:13 you want the KDE upgrader, which has settings for 'upgrade to next', 'upgrade to latest', 'upgrade to random', 'downgrade to last release preferred by people on reddit', and 'upgrade to arch' 18:11:24 plus a button that no-one's sure what it does 18:11:28 Yes, that is DEFINITELY what I want :-D 18:11:39 adamw: Oh, they eliminated the other three nonce buttons? 18:11:42 heh 18:12:12 stickster: it's probably going to wind up being settable per distro just because of how this is actually implemented in g-s, but yeah, i agree. 18:12:42 * stickster notes diminshing returns at this point... maybe time to close this up with #action 18:12:56 I vote for a discussion in mailing list thread. 18:13:24 yup 18:13:27 * adamw writes it 18:14:14 OK, thanks 18:14:56 #action adamw to start discussion about GNOME Software distro-upgrades on @devel list 18:15:07 anything else for today ? 18:15:58 ok, than thanks folks for comming 18:16:10 #endmeeting