17:03:06 <bcotton> #startmeeting F29 Final Go/No-Go meeting
17:03:06 <zodbot> Meeting started Thu Oct 25 17:03:06 2018 UTC.
17:03:06 <zodbot> This meeting is logged and archived in a public location.
17:03:06 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:06 <zodbot> The meeting name has been set to 'f29_final_go/no-go_meeting'
17:03:14 <bcotton> #meetingname F29-Final-Go_No_Go-meeting
17:03:14 <zodbot> The meeting name has been set to 'f29-final-go_no_go-meeting'
17:03:21 <bcotton> #topic Roll Call
17:03:23 <mboddu> .hello mohanboddu
17:03:24 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:03:27 <coremodule> .hello2
17:03:28 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:03:31 <lbrabec> .hello2
17:03:34 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com>
17:03:35 <lruzicka2> .hello lruzicka
17:03:37 <frantisekz> .hello2
17:03:37 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:03:40 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:03:43 <jskladan> .hello2
17:03:43 <zodbot> jskladan: jskladan 'Josef Skladanka' <jskladan@redhat.com>
17:04:48 <sgallagh> .hello2
17:04:49 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:05:22 <bcotton> #topic Purpose of this meeting
17:05:23 <bcotton> #info Purpose of this meeting is to check whether or not F29 Final is ready for shipment, according to the release criteria.
17:05:28 <bcotton> #info This is determined in a few ways:
17:05:29 <bcotton> #info 1. No remaining blocker bugs
17:05:35 <bcotton> #info 2. Release candidate compose is available
17:05:37 <bcotton> #info 3. Test matrices for Beta are fully completed
17:05:42 <bcotton> so....let's do this
17:05:53 <bcotton> #topic Blocker bugs
17:05:53 * stickster lurks
17:06:02 <bcotton> #info 4 Proposed Blockers
17:06:03 <bcotton> #info 1 Accepted Blockers
17:06:09 <coremodule> hi stickster
17:06:15 * bcotton makes lazer noises
17:06:21 <bcotton> time for Mini Blocker Review meeting!
17:06:37 <bcotton> #topic (1642089) Anaconda on netinst media is installing from updates-testing
17:06:38 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1642089
17:06:40 <bcotton> #info Proposed Blocker, anaconda, POST
17:07:13 <frantisekz> so, this isn't happening on RC composes, only pre-release images were affected
17:07:15 <coremodule> -1 Blocker, this works in the RC1.2 compose
17:07:16 <sgallagh> So this should probably not be a blocker for release anymore, as we are going to have all our testing from here on done without this problem
17:07:24 <sgallagh> So I'm -1 blocker on it
17:07:27 <frantisekz> -1b
17:07:38 <lbrabec> -1
17:07:39 <bcotton> great
17:07:48 <bcotton> anyone want to argue for +1?
17:07:53 <mboddu> -1 Blocker
17:08:05 <lruzicka2> -1 blocker, updates-testing is disabled in compose
17:08:12 <coremodule> bcotton, I'll act as secretay this meeting, btw :)
17:08:18 <coremodule> *secretary
17:08:18 <sgallagh> (I don't love that previous testing might not have been entirely valid, but as I expect we're No-Go today, the next week's testing should be fine)
17:08:19 <bcotton> coremodule: thanks!
17:08:43 <frantisekz> sgallagh: I don't expect No-Go, but we'll see :)
17:09:34 <bcotton> proposed #agreed 1642089 - RejectedBlocker - This bug is fixed in RC composes any only affected pre-release images
17:09:40 <frantisekz> ack
17:09:50 <lruzicka2> ack
17:09:51 <jskladan> ack
17:09:51 <lbrabec> ack
17:09:52 <coremodule> ack
17:09:59 <bcotton> #agreed 1642089 - RejectedBlocker - This bug is fixed in RC composes any only affected pre-release images
17:10:09 <bcotton> #topic (1643051) Dragging Activity dock icon for a few seconds causes session to crash
17:10:11 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1643051
17:10:12 <bcotton> #info Proposed Blocker, gnome-shell, NEW
17:10:31 <lbrabec> I wasn't able to reproduce this on clean install
17:10:54 <frantisekz> I wasn't able to reproduce this on AMD/Intel GPUs neither in Wayland nor Xorg sessions
17:11:15 <sgallagh> It also doesn't really hit the bar of "basic operation" in my estimation.
17:11:17 <sgallagh> -1 blocker
17:11:17 <bcotton> the bug has a mix of reproduced and not reproduced
17:11:18 <jskladan> neither kparal was able to reproduce (and that says something...)
17:11:35 <coremodule> I did not hit this bug either, nor did kparal.
17:11:36 <frantisekz> jskladan++
17:11:36 <zodbot> frantisekz: Karma for jskladan changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:11:37 <lbrabec> so I'm -1
17:11:41 <coremodule> what jskladan said :)
17:11:43 <frantisekz> -1 B
17:12:41 <jskladan> -1
17:12:42 <lruzicka2> -1 blocker
17:12:44 <bcotton> proposed #agreed 1643051 - RejectedBlocker - Several testers are unable to reproduce this issue and it's not clear that it falls under the umbrella of "basic operation" for blocker critera
17:12:48 <coremodule> it's possible this is an isolated case of a crash, but since the majority of those who tested did not run into this bug (myself included), I am -1 blocker
17:12:53 <lbrabec> ack
17:12:54 <frantisekz> ack
17:12:55 <coremodule> ack
17:12:56 <jskladan> ack
17:12:59 <lruzicka2> ack
17:13:18 <bcotton> #agreed 1643051 - RejectedBlocker - Several testers are unable to reproduce this issue and it's not clear that it falls under the umbrella of "basic operation" for blocker critera
17:13:28 <bcotton> #topic (1643059) Download button performs the download, but then changes back to Download
17:13:30 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1643059
17:13:31 <bcotton> #info Proposed Blocker, gnome-software, NEW
17:13:50 <coremodule> frantisekz, ^^
17:14:02 <frantisekz> so this is something we should probably discuss more :)
17:14:06 <sgallagh> Being that this is intensely confusing and affects the primary update tool for Workstation, I'm inclined to block on getting this right.
17:14:39 <bcotton> i agree with sgallagh
17:14:41 <bcotton> +1 b
17:15:04 <coremodule> Upon reboot, the user is able to install the updates, so there is a workaround, albeit not an ideal one.
17:15:24 <frantisekz> well, I was more inclined to -1b here, but I see lot of opposition ....
17:15:52 <lruzicka2> the bug, as I have seen it, is in my opinion a cosmetic one rather than a functional one.
17:15:54 <frantisekz> just because users will get updates after reboot, it can be hard to even notice
17:15:57 <jskladan> is anybody else than kparal able to reproduce repeatedly, though?
17:16:13 <frantisekz> I wasn't able to
17:16:21 <frantisekz> it worked just fine for me
17:16:38 <lruzicka2> you can still update the system fine, it is just a rather unintuitive behaviour here, could be fixed post release as an update
17:16:47 <coremodule> I was also unable to reproduce this.
17:16:52 * stickster_mac trying to reproduce a bug, had to restart, then found out there was >= 1 firmware update waiting to flash. Taking longer than needed.
17:17:06 <sgallagh> lruzicka2: Assuming you can figure out how to GET that update, if you hit this bug...
17:17:18 <stickster_mac> Sounds like the bug you guys are on now.
17:17:29 <jskladan> and/or is a fix going to land before the next go/nogo (as I'm not seeing any comments other than kparal's in that bug)?
17:17:31 <lruzicka2> sgallagh, the updates were pulled in in the background, no action needed.
17:17:37 <lruzicka2> at my place, at least
17:17:54 <stickster_mac> sgallagh: If someone's on the release, they won't see previous problems, right? And if they're already on a pre-GA clearly they get to keep the pieces.
17:18:08 <sgallagh> I *think* the condition to hit this is that you have to get to this at a time between "PK notices that there are updates" and "PK downloads those updates in the background"
17:18:17 <sgallagh> Which *should* be easier to hit with a refresh
17:18:21 <stickster_mac> hmm, I see
17:18:44 <jskladan> (just asking, as this has quite straightforward workaround, and we IMO had way more confusing issues "just" common-bug-ed)
17:18:52 <jlanda> I actually hit PK in background almost everytime after installing a non live flavour
17:20:16 * stickster_mac has the PK that was mentioned in the bug. I received the notice, called up Software, did Restart & Update, and it appears to be working as expected. That doesn't invalidate what sgallagh said
17:21:01 <sgallagh> If everyone else feels that the workaround is sufficient, go ahead and override me.
17:21:01 <jlanda> lruzicka2: an unintuitive behaviour on the default update software on wks ;)
17:21:10 <lruzicka2> When I was fiddling with this one, I hit Download it changed to Cancel. Worked as expected but did not show progress.
17:21:36 <stickster_mac> I'm just having a hard time seeing how insidious the problem is here, not saying it's not
17:21:40 <coremodule> sgallagh, Did you run into this bug?
17:22:03 <jlanda> I'm on +1b on this, it's not a random app that need an update, it's the updating app
17:22:10 <frantisekz> "ordinary users" wouldn't notice this at all (updating on reboot), and workaround is so simple (you probably wouldn't even notice it)
17:22:14 <frantisekz> I am -1 here
17:22:17 <sgallagh> coremodule: I have not; my pk has already downloaded the packages in the background
17:22:19 <lruzicka2> jlanda, I would rather wish for a nicely working progress bar. Some people have that. I did not. But it is working.
17:22:39 <jlanda> yeah, it's working, I agree
17:22:48 <lruzicka2> I would say -1 with a note in common bugs
17:23:25 <lbrabec> I'm like -0.5 here
17:23:46 <bcotton> looks like we're +2, -2.5 righ tnow
17:24:07 <frantisekz> lbrabec ... let's use int only :)
17:24:29 * jskladan is -1b +1 common bug
17:24:34 * stickster kicks out that pretender
17:24:49 <jlanda> let go then
17:25:13 <lruzicka2> Last time, we common bugged this one: 🔗 Login to Desktop impossible after upgrade to Fedora 28
17:25:31 <lruzicka2> This is the same rank, I would say.
17:25:32 <stickster> ha
17:25:39 <stickster> at worst.
17:25:41 <bcotton> okay, so we're net -1.5. any of the +1 want to make a stand on this one?
17:25:42 <sgallagh> Link please?
17:25:57 <coremodule> I'm -1 blocker, it's ugly when it rears it's head, but I personally haven't encountered it, and based on kparal's findings, it can be sorted out by a reboot, which most users are going to do after install.
17:25:58 <lruzicka2> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1227736
17:26:05 <coremodule> +1 common bugs
17:26:23 <coremodule> For clarity, -1 blocker, +1 commonbug
17:27:39 <sgallagh> I submit to the will of the majority, but reserve the right to say "I told you so" :)
17:28:10 <mboddu> I am not able to reproduce the bug, but that doesn't mean I am -1B it
17:28:12 <bcotton> okay, so it seems like we're trending negative
17:28:18 <coremodule> lol
17:28:29 <frantisekz> sgallagh: you'll be the only one not fired if it explodes somehow after GA.... smart move :)
17:28:44 <coremodule> .fire everyone
17:28:44 <zodbot> adamw fires everyone
17:28:56 <coremodule> .fire everyone except sgallagh
17:28:56 <zodbot> adamw fires everyone except sgallagh
17:29:18 <sgallagh> bcotton: results?
17:29:39 <bcotton> if i'm counting right, we're -2.5 now
17:29:43 <bcotton> proposed #agreed 1643059 - RejectedBlocker - Several testers cannot reproduce this. Since there is a workaround it will be added to Common Bugs in case users encounter it.
17:29:52 <lruzicka2> ack
17:29:52 <frantisekz> ackitty ack
17:29:54 <lbrabec> ack
17:29:55 <sgallagh> ack
17:30:00 <sgallagh> frantisekz: Don't talk back
17:30:07 <mboddu> ack
17:30:10 <bcotton> sgallagh++
17:30:13 <bcotton> #agreed 1643059 - RejectedBlocker - Several testers cannot reproduce this. Since there is a workaround it will be added to Common Bugs in case users encounter it.
17:30:15 <frantisekz> sgallagh++ :)
17:30:15 <zodbot> frantisekz: Karma for sgallagh changed to 15 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:30:24 <bcotton> #topic (1642796) PackageKit terminated before end of offline update
17:30:26 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1642796
17:30:27 <bcotton> #info Proposed Blocker, libdnf, NEW
17:30:46 <frantisekz> so, this should be caused, according to dnf team, by using old libdnf
17:31:14 <sgallagh> frantisekz: Does old == earlier than the one currently in stable for RC 1.2?
17:31:21 <frantisekz> and nobody with latest libdnf (which is in stable F29) was able to reproduce it
17:31:24 <frantisekz> sgallagh: yep
17:31:27 <sgallagh> ok
17:32:11 <frantisekz> so, I am -1 here
17:32:56 <sgallagh> I'm a little concerned that QA hasn't *validated* that this is fixed, though
17:33:22 <sgallagh> I think I'd block on this if it's not fixed.
17:33:48 <sgallagh> +1 blocker, we must prove we can't reproduce it with RC 1.2 before we say "Go"
17:33:50 <contyk> .hello psabata
17:33:51 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
17:33:57 * contyk is late
17:34:02 <bcotton> welcome, contyk
17:34:14 <frantisekz> we've noticed the issues just after libdnf-0.22.0-6 landed in stable, as pschindl accidentally tried update with old version
17:34:27 <sgallagh> Phrased differently: if it turns out -6 didn't fix it, I don't think we should ship without doing so
17:35:27 <lruzicka2> sgallagh, all dnf related tests in openqa passed, the libdnf version is 0.22 in compose
17:36:15 <lruzicka2> the libdnf version is exactly 0.22.0-6
17:36:21 <frantisekz> sgallagh: I can  fire up vm right now and retest it if you want?
17:36:33 <sgallagh> frantisekz: please
17:36:43 <mboddu> I agree with sgallagh
17:37:38 <coremodule> I also agree with sgallagh, we need to test and make sure this is no longer the case before we ship.
17:38:18 <bcotton> frantisekz: how long do you need to test it? we can move on to the accepted blocker and come back to this one
17:38:21 <sgallagh> I think what we're agreeing to is this: This *is* a blocker but it *may* be fixed already.
17:38:37 <frantisekz> 15' minutes-ish
17:38:42 <mboddu> bcotton: +1, we can comeback to this one then
17:38:44 <bcotton> okay, then we'll table this
17:38:51 <jlanda> +1 sgallagh
17:38:58 <bcotton> #info We will table this bug while frantisekz tests
17:39:16 <bcotton> #topic (1640701) GNOME Software "update and restart" button appears to do nothing
17:39:17 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1640701
17:39:19 <bcotton> #info Accepted Blocker, gnome-software, ON_QA
17:39:47 <coremodule> frantisekz, ^^
17:40:30 <coremodule> This should be fixed in the latest gnome-software that will land in the compose, should we decide to ship, but I defer to frantisekz as he knows more about this one.
17:41:05 <frantisekz> fix is in RC compose
17:41:12 <frantisekz> I'll file it to the stable repo
17:41:18 <bcotton> #info fix is in the RC1.2 compose
17:41:37 <sgallagh> frantisekz: VERIFIED?
17:42:49 <frantisekz> yep
17:42:59 <sgallagh> frantisekz++
17:42:59 <zodbot> sgallagh: Karma for frantisekz changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:43:44 <contyk> yay
17:44:26 <bcotton> #action frantisekz to request fix pushed to stable
17:45:04 <bcotton> proposed #agreed 1640701 is fixed and no longer blocks the release
17:45:25 <coremodule> ack
17:45:42 <sgallagh> ack
17:45:45 <lruzicka2> ack
17:46:10 <bcotton> #agreed 1640701 is fixed and no longer blocks the release
17:46:42 <bcotton> frantisekz: are you ready for us to come back to 1642796?
17:47:23 <frantisekz> bcotton: not yet, it's pretty difficult to get the broken state now :)
17:47:47 <bcotton> i suppose that's a good thing
17:48:28 <bcotton> frantisekz: do you want us to move on to the RC and test matricies?
17:48:31 <sgallagh> I'm willing to accept "frantisekz can no longer find a way to reproduce it" as a sufficient stand-in for "VERIFIED" here.
17:48:43 <frantisekz> sgallagh: ok
17:48:54 <contyk> but that's not what he's saying, is it :)
17:50:49 <bcotton> frantisekz: do you want to keep working on it or should we vote with the information we have?
17:51:02 <frantisekz> sgallagh: I wasn't able to reproduce the issue with old libdnf , neither with new, just noting that new libdnf was part of the upgrade, so that might have helped
17:51:13 <sgallagh> hmm
17:51:19 <sgallagh> I'm not sure that's good enough
17:52:43 <contyk> it probably isn't
17:52:48 <sgallagh> I'm going to attempt to repro this as well.
17:52:50 <jskladan> sgallagh: will this opinion change in time? As this has no reproducer, it is pretty damn hard to "prove it not reproducible". I mean - what if we can't get to the broken state next time, or the next one? (just as a note, I'm also trying quite hard to get a machine to that broken state)
17:52:51 <lruzicka2> the bug was reported by Petr who did not have a standard installation of system, not did he have correct updates.
17:52:58 <sgallagh> Give me five minutes
17:53:05 <jskladan> sgallagh++
17:53:05 <zodbot> jskladan: Karma for sgallagh changed to 16 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:53:09 <bcotton> sgallagh: you have 5 minutes :-)
17:53:11 <bcotton> in the meantime...
17:53:21 <bcotton> #topic Current Status — Release Candidate
17:53:51 <bcotton> #info RC1.2 is available
17:53:54 <bcotton> #link http://dl.fedoraproject.org/pub/alt/stage/29_RC-1.2/
17:53:59 <bcotton> so...what can be said for RC1.2?
17:54:36 <frantisekz> arrived pretty late, it was really tough testing session today :)
17:54:46 <bcotton> i'm a little concerned that RC1.2 appears to only be half a day old
17:54:57 <bcotton> well, i guess three quarters of a day at this point
17:55:40 <lruzicka2> we have had two no goes already ... the RC is a result of previous composes
17:55:41 <coremodule> While RC1.2 is new, test coverage is good, many of the tests are completed. Should we slip, another week will further polish out the remaining tests that haven't been run on RC1.2, but as it stands QA feels comfortable saying that RC1.2 has been thoroughly tested per the standards given in the QA SOP.
17:56:03 <frantisekz> coremodule++
17:56:03 <zodbot> frantisekz: Karma for coremodule changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:56:10 <coremodule> See the testcase stats here: https://www.happyassassin.net/testcase_stats/29/
17:56:13 <bcotton> #info QA feels comfortable saying that RC1.2 has been thoroughly tested per the standards given in the QA SOP
17:56:20 <bcotton> #link https://www.happyassassin.net/testcase_stats/29/
17:56:26 <mboddu> bcotton: I am little skeptical about releasing something that is tested for less than a day
17:56:27 <coremodule> Here is a different version of the same information: https://fedoraproject.org/wiki/Test_Results:Fedora_29_RC_1.2_Summary?rd=Test_Results:Current_Summary
17:56:35 <coremodule> Which I'm sure you've all seen.
17:56:48 <bcotton> mboddu: i'm with you on that
17:56:59 <frantisekz> mboddu: F29 has been tested for a while now
17:57:09 <sgallagh> I have not had a chance to run the Active Directory domain tests in F29 since Beta. That coverage is missing, but I’m not terribly worried about it.
17:57:29 * jskladan is not seeing "release must be older than X days" in the release criteria mboddu :)
17:57:37 <frantisekz> just because RC 1.2 is fresh doesn't mean we didn't test basically the same packages for a few weeks now
17:57:44 <mboddu> frantisekz: True, but still just a concern
17:57:48 <jskladan> s/release/release candidate/
17:59:04 <bcotton> anything else we want to say about RC 1.2? assuming we don't block on that outstanding bug, it will be the RC we give a go/no-go to in a few minutes
17:59:04 <mboddu> jskladan: Well, there is an unspoken criteria, release engineering should get a RC request at least 2 days before go, no-go which didn't happen, but that is a soft criteria just so that we will have enough testing done before the meeting
17:59:33 <lruzicka2> from my perspective, we have been testing composes for a go meeting two weeks ago ... found some bugs, retested them, another go meeting passed ... I see the RC as a product of two weeks testing. not a day or so.
17:59:35 <bcotton> and we'll cover test case coverage in more detail momentarily
18:00:25 <bcotton> sgallagh: are you ready for us to come back to that bug?
18:00:32 <sgallagh> I’ve just completed my testing. I cannot make the offline tests fail, which is good enough for me.
18:00:38 <bcotton> ok
18:00:46 <bcotton> #topic (1642796) PackageKit terminated before end of offline update
18:00:47 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1642796
18:00:49 <bcotton> #info Proposed Blocker, libdnf, NEW
18:00:50 <sgallagh> s/tests/updates
18:01:37 <bcotton> proposed #agreed 1642796 - RejectedBlocker - Testers cannot reproduce the issue with up-to-date systems
18:01:43 <frantisekz> ack
18:01:49 <mboddu> ack
18:01:54 <jlanda> ack
18:01:55 <contyk> I guess
18:01:56 <lbrabec> ack
18:01:58 <lruzicka2> ack
18:02:20 <bcotton> contyk: now's your chance to object if you want :-)
18:02:33 <sgallagh> ack
18:02:37 * stickster looks
18:02:51 <contyk> I'm not convinced it's fixed but it's just a feeling :)
18:03:13 <jskladan> mboddu: ad "non-mature RC": I sure can see your point, but I've had my share of hero-testing days, and this was never an issue, to my knowledge. I could be sad here, and say that "if I knew RC has to be at least X-days old" is a release criterion, we might just go home a couple hours earlier, and do the same work in two days instead of one...
18:03:25 * stickster just did an update with latest 0.22.0-6 and didn't see this problem
18:03:32 <bcotton> \#agreed 1642796 - RejectedBlocker - Testers cannot reproduce the issue with up-to-date systems
18:03:36 <bcotton> gah
18:03:39 <bcotton> #agreed 1642796 - RejectedBlocker - Testers cannot reproduce the issue with up-to-date systems
18:03:43 <coremodule> lruzicka2 has a point, with the few packages that have changed, the majority remained the same. Not saying that those changes couldn't break other things, but with the coverage that we do have, that does satisfy the requirements as far as QA is concerned, it looks like the release is solid. We'll always find new bugs after launch, we always do, but showstoppers... at this point I think we have eliminated a good many of them. mboddu,
18:03:43 <coremodule> perhaps we should turn that unspoken criteria into a hard one, so that we have something in stone to go off of for the future.
18:03:48 <bcotton> okay, so let's get back to the test coverage
18:03:55 <bcotton> #topic Current status - test coverage
18:04:06 <bcotton> #link https://www.happyassassin.net/testcase_stats/29/
18:04:48 <bcotton> i'm a little concerned about some of the modularity tests in https://www.happyassassin.net/testcase_stats/29/Installation.html
18:05:24 <bcotton> given that modularity is a big part of F29, the fact that the tests all say "Beta" is worrying (unless i'm misreading it)
18:05:29 <lruzicka2> Adam moved them to Base, bcotton
18:05:31 <frantisekz> bcotton: https://fedoraproject.org/wiki/Test_Results:Fedora_29_RC_1.2_Summary?rd=Test_Results:Current_Summary#Modularity
18:05:35 <frantisekz> it's here
18:05:38 <frantisekz> it's been tested
18:05:51 <bcotton> great! i withdraw my concern :-)
18:06:07 <lruzicka2> the one failing is the Fesco bug that was not taken as a blocker
18:06:48 <sgallagh> coremodule: I've proposed making that a hard proposal in the past and been rebuffed.
18:06:58 <coremodule> Coverage is solid, we have testing done for the majority of test cases on RC1.2, and those that aren't tested have been tested recently, as seen here: https://www.happyassassin.net/testcase_stats/29/
18:07:02 <mboddu> jskladan: Well, I am not saying that we should make it a criterion, but it helps if we can follow it
18:07:06 <sgallagh> The argument being "If QA is willing, they shouldn't be FORCED, but may decide that the time is sufficient"
18:07:35 <bcotton> #info  Coverage is solid, we have testing done for the majority of test cases on RC1.2, and those that aren't tested have been tested recently
18:07:48 <bcotton> anything else we want to say about test coverage?
18:08:22 <coremodule> sgallagh, I can see it both ways, I mean it is on QA if they don't get the request to releng on time, but a late request also shouldn't put the releng folks in a stressful situation of having to rush to get it done.
18:08:37 <coremodule> nothing here bcotton.
18:08:46 <mboddu> coremodule: Sure, its just a concern and if QA is confident about the testing, then I trust them and I am okay with it :)
18:09:33 <bcotton> okay, i'll move on to the decision process then
18:10:18 <bcotton> #topic Go/No-Go decision
18:10:27 <bcotton> before we start making up our mind, there's a consideration
18:10:46 <bcotton> #info November 6 is the 15th anniverary of the Fedora Core 1 release
18:10:51 <contyk> :))
18:11:08 <contyk> we should release f30 then
18:11:23 <bcotton> from a marketing standpoint, there's some value in waiting a week to release even if we decide we're go today
18:11:24 <sgallagh> October 31st is the anniversary of the RHL release, isn't it?
18:11:32 <mboddu> contyk: Hehe, lets just a rawhide compose and say its the F30 release :)
18:11:39 <bcotton> sgallagh: i believe you're correct
18:11:41 <frantisekz> mboddu++
18:11:51 <contyk> mboddu: exactly :)
18:11:53 <jskladan> mboddu++
18:11:53 <zodbot> jskladan: Karma for mohanboddu changed to 22 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:12:06 <bcotton> fwiw, mattdm expressed support for releasing on the anniversary
18:12:16 <coremodule> bcotton, Can you explain the advantage from a marketing standpoint?
18:12:22 <bcotton> sure
18:13:11 <bcotton> the advantage is that it gives us a nice neat milestone for the tech press to point to. this release isn't super flashy in a lot of ways, and the press loves nice round milestones
18:13:41 <bcotton> the fact that we have the opportunity to do a release 15 years to the day is compelling
18:14:05 <bcotton> it's not unassailably compelling, but it does add a little bit to it
18:14:07 <sgallagh> If we delayed, would we be doing a "full slip" where additional FEs could come in? Or declaring Go and then just delaying the actual release to hit the date?
18:14:35 <bcotton> well that's something we'd have to decide
18:14:42 <lruzicka2> sgallagh, if we should delay, I'd go with the second option
18:14:55 <bcotton> there's a chance we'd hit additional blockers and whatnot
18:14:59 * Southern_Gentlem rather see a slip and we have time to test and be sure things are fixed
18:15:06 <sgallagh> bcotton: I think if we aren't slipping to fix blockers, the press is more likely to have a field day with "Fedora slips even when it doesn't need to!" than "Hey look, an anniversary!"
18:15:16 <frantisekz> on the contrary, we can say we've released on time (again) if we don't slip :)
18:15:47 <lruzicka2> bcotton, if we hit more blockers, we might have a blocker review to see whether it is so serious we need another compose.
18:15:49 <bcotton> frantisekz: well i can always add another "totally our real release target" to the schedule to keep phoronix happy
18:15:56 <lruzicka2> bcotton, but otherwise, I would not touch it.
18:15:56 <sgallagh> bcotton: I feel like there's more opportunity for a one-two punch if we release next week and then have a 15-year celebration the week after.
18:16:00 <frantisekz> bcotton++ :)
18:16:05 <sgallagh> We can keep our name in the press longer that way
18:16:13 <bcotton> lruzicka2: yeah, we'd want to keep an eye on any potential blockers that come up
18:16:18 <bcotton> sgallagh: that's also a good point
18:16:31 <mboddu> sgallagh: From releng prespective, if we are slipping then I wouldn't want to start working on the release right now rather than wait and do more testing and start working on the release next Thu
18:16:57 <contyk> sgallagh: +1
18:16:59 <coremodule> At this point, based on the fact that all blockers have been taken care of in one way or another and the amount of validation testing has been found to be sufficient to complete the test matrices, it's QA policy to vote GO. That said, I do see the benefit and "cool" factor of waiting a week for additional polish's sake, as well as satisfying the press and marketing guys.
18:16:59 <bcotton> i think a lot of it will depend on how beneficial QA thinks another week of testing would be
18:17:08 * stickster feels like, if we're ready, we're ready. And if people keep finding bugs, that may upset the apple cart with a previously unseen blocker. If that happens just before we'd normally "go to release," ugh
18:17:53 <sgallagh> bcotton: Another week of testing is likely to lead to additional blockers, in my experience.
18:17:59 <stickster> ^ that.
18:18:04 <coremodule> ^^ that. :)
18:18:13 * jskladan does not really see a particularly _technical_ reason to slip ATM. But I'm no press expert, if that's what's important for us now
18:18:20 <bcotton> what if we just break the blocker app? ;-)
18:18:21 <stickster> ^^^ thatitty that
18:18:25 <lruzicka2> or, if not blockers, then allowed FEs that will break somthing
18:19:33 <bcotton> yeah, the longer we wait, the more bugs we find. but given the last minute churn in libdnf and packagekit, is it worth giving those some extra testing to make sure we catch them before the release goes out?
18:19:37 <bcotton> that's not a leading question
18:19:54 <frantisekz> I feel like getting two opportunities to get to the press (once for release, once for anniversary) is a good thing as sgallagh suggested
18:20:10 <sgallagh> bcotton: Like I said, if we spend another week hammering on the two most fragile bits of the distro, we WILL find new bugs, which in turn will lead to yet more changes.
18:20:24 <sgallagh> DNF/PK rarely submit solo changes, instead preferring upstream rebases
18:20:29 <sgallagh> So that's a lot of churn
18:21:04 <coremodule> bcotton, I can see waiting and providing more testing. sgallagh makes a good point about upstream rebasing and the DNF/PK folks.
18:21:15 <coremodule> *though.^
18:21:24 <sgallagh> *IF* the anniversary is compelling enough, I'd prefer we at least declare that RC 1.2 is what ships.
18:21:54 <bcotton> yeah. my concern is that i'd rather find the worst bugs pre-release. but we won't know what will be found until we find it
18:22:29 <stickster> sgallagh: ^ that would be acceptable. IOW, call a halt to bug excavating.
18:22:40 <sgallagh> We will always find new bugs. Right now, we've hit a point where everyone seems to agree that we've fixed all the ones we know about.
18:22:42 <bcotton> #info Fedora Marketing says (via telegram, as no one is able to join IRC currently) they like the idea of aligning to the anniversary
18:23:13 <stickster> bcotton: sgallagh: Here's another thought, we are also then artificially extending infra freeze and that sucks
18:23:24 <bcotton> marketing also points out a week with an RC gives them a chance to create more content around the release
18:23:29 <stickster> we already have people on hold for that. Every day is more things that can't be changed.
18:23:53 <stickster> bcotton: Based on output, that's a hard justification to sell (mktg)
18:24:09 <bcotton> stickster, can you share some specifics on what we're holding? just so we're all aware
18:24:14 <Southern_Gentlem> imho release if we are releasing do it next week
18:24:19 <bcotton> stickster: point taken, i'm just passing the message
18:24:29 <Southern_Gentlem> we will get the press both weeks
18:24:39 <stickster> bcotton: it's *any current or potential change* that affects infra, which can't be handled trivially in a freeze break request.
18:25:09 <coremodule> "...with their latest release just last week, the Fedora team remains steadfast in keeping the latest and greatest in the OS, just as they originally set out to do 15 years ago."
18:25:22 <sgallagh> coremodule++
18:25:22 <zodbot> sgallagh: Karma for coremodule changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:25:23 <bcotton> stickster: right, but how big's the queue? any we holding back anything that we really want to do sooner rather than later?
18:25:24 <contyk> I still like sgallagh's proposal where we release on time and then celebrate a week later
18:25:46 <coremodule> ^hey, it's an attempt ;P
18:25:48 <mboddu> coremodule++
18:25:57 <Southern_Gentlem> coremodule++
18:25:59 <bcotton> coremodule needs to join #fedora-mktg
18:26:00 <stickster> bcotton: I don't know the queue size. We'd have to ask Evolution, or rbarlow, pingou, puiterwijk, etc.
18:26:05 <bcotton> ok
18:26:10 <sgallagh> And remember that we *could* defer a single day and release on the 24th anniversary of RHL 0.9 ...
18:26:10 <stickster> The queue in terms of issues is always large ;-)
18:26:21 <bcotton> so we could probably debate this until 6 November
18:26:26 <stickster> lol, yup
18:26:32 <bhavin192> coremodule++
18:26:32 <zodbot> bhavin192: Karma for coremodule changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:26:53 <bhavin192> bcotton, hehe
18:27:02 * stickster notes, he would defer to FPL if there's a really strong justification other than "it sounds nice," like an expanded media plan
18:27:16 <coremodule> hahaha
18:27:17 <stickster> I mean, in actuality I defer no matter what :-D
18:27:20 <sgallagh> Unfortunately, Fearless Leader is on PTO today
18:27:20 <bcotton> i'm going to say let's break it into two decisions: 1. is RC1.2 go for F29 Final? 2. do we release it on Oct 30 or Nov 6
18:27:22 <bcotton> haha
18:27:33 <stickster> bcotton: good call
18:27:46 <sgallagh> bcotton: Or Oct 31 ;-)
18:27:49 <lruzicka2> bcotton, yeah let's do it
18:27:56 <contyk> maybe we'll be no-go all the way through january
18:28:06 <mboddu> sgallagh: No more options please :)
18:28:11 <stickster> contyk: I'm holding that card for next release, don't jump the gun ;-)
18:28:15 <sgallagh> bcotton: (Do ask the mktg folks about the RHL anniversary; it might satisfy them)
18:28:17 <bcotton> stickster: fwiw, "this time around I think we should take caution and make sure we're confident about all of the issues around libdnf and packagekit and basically anything else which could prevent users from updating their systems." is what mattdm said on the QA mailing list this morning
18:28:26 <stickster> sgallagh: yeah, stop with the options :-D
18:28:32 <stickster> http://islinuxaboutchoice.com/
18:28:42 <coremodule> lol
18:28:50 <stickster> that's fair
18:28:52 <sgallagh> 🤪
18:28:55 <bcotton> okay, here we go. i'll poll the three teams on RC1.2
18:28:57 <kalev-afk> I just got back at the computer
18:29:04 <kalev-afk> did you guys not accept the gnome-software blocker? :(
18:29:22 <bcotton> kalev-afk: we rejected all proposed blockers
18:29:43 <kalev> I don't really feel comfortable shipping a release like this. the bug prevents updating which I think is really serious
18:30:00 <sgallagh> kalev: None of us could reproduce the bug.
18:30:14 <sgallagh> stickster and I each performed an update using Software *during* the discussion.
18:30:19 <lruzicka2> kalev, it does not. it only does not look nice. it works in the background
18:30:38 <kalev> sure, it probably depends on the package set. kparal updated from Beta package set and had a larger number of updates to apply, which is why he managed to trigger it, I think
18:31:18 <stickster> but we don't ship with a primary basis of can you update from Beta, right? As long as there's a workaround in that case
18:31:42 <stickster> anyway, we're kind of going backward in the agenda right now.
18:31:48 <bcotton> yeah, let's move forward
18:31:55 <bcotton> #topic RC1.2 Go/No-Go decision
18:32:00 <bcotton> FESCo?
18:32:01 * stickster not dismissing kalev concerns
18:32:08 <jskladan> kalev: you are talking about 1642796, right? Thing is, there is not really a reproducer at all... So how do you propose we test whether it is fixed or not? Also, what stickster said...
18:32:16 <sgallagh> Go
18:32:21 <bcotton> #info FESCo is go
18:32:25 <bcotton> Releng?
18:33:00 <kalev> jskladan: no, I'm talking about https://bugzilla.redhat.com/show_bug.cgi?id=1643059
18:33:00 <mboddu> Go
18:33:05 <bcotton> #info Releng is go
18:33:07 <bcotton> QA?
18:33:10 <coremodule> Go
18:33:17 <bcotton> #info QA is go
18:33:35 <bcotton> proposed #agreed RC1.2 is go as Fedora 29 Final
18:33:49 <contyk> that was quick
18:34:00 <smooge> Infrastructure is og
18:34:14 <smooge> if that is still needed these days
18:34:29 <bcotton> smooge: it's not explicitly, but maybe it should be
18:34:38 <bcotton> smooge: but it's good to know that you're go :-)
18:34:49 <bcotton> seeing no nacks
18:34:51 <bcotton> #agreed RC1.2 is go as Fedora 29 Final
18:34:57 <puiterwijk> bcotton, smooge: I believe that's why there's go/no-go and readyness, separate.
18:35:00 <jskladan> yay
18:35:18 <bcotton> #topic F29 Final release date
18:35:39 <smooge> oh sorry different meeting
18:35:41 <smooge> my apologies
18:35:59 <bcotton> so i guess we'll do this by vote of folks in the room. the choices are 30 Oct and 6 Nov. i'll tally them as you yell them at me
18:36:21 <bcotton> 6 Nov for me
18:36:32 <frantisekz> 30 Oct for me
18:36:37 <jskladan> +1 30 oct
18:36:44 <mboddu> bcotton: If we decide for 6 Nov, does that mean if we find bugs, we might respin another compose?
18:36:48 <lruzicka2> I am fine with both.
18:37:00 <Cygnia> 30 Oct
18:37:02 <bcotton> mboddu: only if we have to
18:37:08 <bhavin192> 30 Oct
18:37:13 <smooge> 31 Oct for me
18:37:18 <puiterwijk> 1 Nov
18:37:27 * Evolution looks at smooge
18:37:30 <bcotton> /kick puiterwijk
18:37:32 <Evolution> we already had a halloween release
18:37:42 <mboddu> bcotton: Then I am with 6th Nov
18:37:42 <Evolution> bcotton: out of curiosity, why would you want to wait
18:38:12 <bcotton> Evolution: to land on the 15th anniversary of FC1
18:38:19 <smooge> it has been a very very long goal to have another.. if we can bring back condiments and other things I can't pass up Halloween 2
18:38:36 <kalev> this is the worst of both worlds: declare RC1.2 gold and then wait until 6 Nov. If you want to wait until 6 Nov, don't declare it Gold so that we can fix up the remaining bugs in the update process.
18:38:40 <contyk> 30 Oct
18:39:15 <coremodule> kalev, The thought is that since will undoubtedly find new bugs, we stick with what we know, should we decide to ship on Oct 6.
18:39:21 <coremodule> *since we will
18:39:28 <bcotton> kalev: is that a vote for 30 Oct, then?
18:39:47 <kalev> no, my vote is 6 Nov and not call this RC 1.2 Gold
18:39:47 <bhavin192> kalev++
18:39:47 <zodbot> bhavin192: Karma for kalev changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:39:50 <sgallagh> 30 or 31
18:40:04 <kalev> coremodule:  this is just backwards. we should fix the things up that we found, not say that we inevitably find more
18:40:16 <ksinny> 30 Oct if RC 1.2 is Gold
18:40:35 * mboddu agrees with kalev
18:40:40 <bcotton> i count 8 for 30 Oct and 3 for 6 Nov
18:40:55 <bcotton> last call for votes (and i wrote nicks down so don't try to vote twice on me)
18:41:06 <coremodule> +1 Oct 30
18:41:09 <coremodule> +1 Nov 6
18:41:12 <coremodule> ;)
18:41:18 <coremodule> Don't count either of those.
18:41:21 <bcotton> .fire coremodule
18:41:21 <zodbot> adamw fires coremodule
18:41:22 <sneaky_josev> +1 0ct 30
18:41:34 <coremodule> I'm too indecisive.
18:41:46 <bcotton> coremodule: do you have no coins to flip? ;-)
18:42:03 <bcotton> proposed #agreed Fedora 29 Final will be released on 2018-10-30
18:42:22 <contyk> ack
18:42:28 <frantisekz> ack
18:42:52 <coremodule> Nov 6 and give us another week to test.
18:43:20 <coremodule> There's my vote. It's late, but.
18:43:25 <coremodule> ack
18:43:31 <bcotton> #agreed Fedora 29 Final will be released on 2018-10-30
18:43:43 <bcotton> and there was much rejoicing
18:43:51 <bcotton> #action bcotton to announce decision
18:43:59 <mboddu> Oh well, one way to look at it, we are not slipping :)
18:44:01 <bcotton> #topic Open floor
18:44:06 <contyk> now let's find a major critical bug
18:44:10 <mboddu> 2 releases in a row that we are shipping on time
18:44:21 <bhavin192> \o/
18:44:30 * jskladan rejoice https://www.purina.co.uk/sites/g/files/mcldtz776/files/styles/nppe_article_listing_image_and_description/public/2018-01/Bringing-Your-Kitten-Home_0_2.jpg?itok=U1yah_UD
18:44:40 <bcotton> #info Next Go/No-Go meeting will be F30 Beta in March 2019
18:44:58 * mboddu got to run
18:45:01 <mboddu> Thanks bcotton
18:45:02 <bcotton> anything else before we go off to kick the bits out the door?
18:45:06 <bcotton> thanks mboddu
18:45:39 <coremodule> Nothing here! Glad we made a decision. :)
18:45:47 <bcotton> we tried out best not to ;-)
18:45:59 <bcotton> our best, too
18:46:12 <frantisekz> thanks all (and especially bcotton for leading the mtg)!
18:46:14 <bcotton> okay, thanks everyone! off to bigger and better Fedora 30s!
18:46:19 <bcotton> #endmeeting