17:00:30 <bcotton> #startmeeting F29 Beta Go/No-Go meeting
17:00:30 <zodbot> Meeting started Thu Sep 13 17:00:30 2018 UTC.
17:00:30 <zodbot> This meeting is logged and archived in a public location.
17:00:30 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:30 <zodbot> The meeting name has been set to 'f29_beta_go/no-go_meeting'
17:00:32 <bcotton> #meetingname F29-Beta-Go_No_Go-meeting
17:00:32 <zodbot> The meeting name has been set to 'f29-beta-go_no_go-meeting'
17:00:38 <bcotton> #topic Roll Call
17:00:42 <contyk> .hello psabata
17:00:43 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
17:00:45 <frantisekz> .hello2
17:00:46 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:01:24 <bowlofeggs> .hello2
17:01:25 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
17:01:34 <adamw> .hello adamwill
17:01:35 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:01:38 <cverna> hello
17:01:48 <mboddu> .hello mohanboddu
17:01:49 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:02:43 <nirik> morning
17:03:01 <bcotton> i see we have at least one person here from FESCo, RelEng, and QA, so let's go ahead and get this party started
17:03:12 <bcotton> #topic Purpose of this meeting
17:03:14 <bcotton> #info Purpose of this meeting is to check whether or not F29 Beta is ready for shipment, according to the release criteria.
17:03:26 <bcotton> #info This is determined in a few ways:
17:03:27 <bcotton> #info 1. No remaining blocker bugs
17:03:35 <bcotton> #info 2. Release candidate compose is available
17:03:36 <bcotton> #info 3. Test matrices for Beta are fully completed
17:04:09 <contyk> so we still have several proposed and one accepted
17:04:27 <bcotton> #topic Blockers
17:04:34 <bcotton> #link https://qa.fedoraproject.org/blockerbugs/milestone/29/beta/buglist
17:05:04 <bcotton> do we want to do a quick blocker review on these 7?
17:05:18 * contyk nods
17:05:33 <mboddu> bcotton: Yes
17:05:54 <bcotton> okay, here's the first
17:05:56 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1592686
17:06:13 <adamw> shall I do it?
17:06:21 <bcotton> go ahead, adamw
17:06:27 <bcotton> #chair adamw
17:06:27 <zodbot> Current chairs: adamw bcotton
17:06:40 <adamw> bcotton: for future reference, you can get the magic Official Format at https://qa.fedoraproject.org/blockerbugs/milestone/29/beta/irc
17:06:49 <adamw> well, change the 29/beta of course :)
17:06:53 <bcotton> fancy. duly noted
17:06:58 <adamw> go to http://qa.fedoraproject.org/blockerbugs/current then click 'IRC Format'
17:07:09 <adamw> we have:
17:07:09 <adamw> #info 7 Proposed Blockers
17:07:09 <adamw> #info 1 Accepted Blockers
17:07:16 <adamw> #info starting with proposed...
17:07:21 <adamw> #topic (1592686) the installer will hang there if inst.vncpassword boot option is added
17:07:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1592686
17:07:21 <adamw> #info Proposed Blocker, anaconda, NEW
17:07:41 <adamw> as noted in bug i'm -1 blocker on this, it's been around quite a while but it's specifically in vncpassword, regular vnc works ok
17:07:46 <contyk> I think I agree with adamw
17:08:01 <bowlofeggs> -1
17:08:13 <mboddu> -1 Blocker
17:08:13 <frantisekz> -1
17:08:16 <nirik> -1 here too
17:10:24 <adamw> proposed #agreed 1592686 - RejectedBlocker (Beta) - this only affects passworded VNC, and the criterion doesn't require that to work, just 'VNC'. which does work
17:10:36 <frantisekz> ack
17:10:47 <contyk> +1 to the proposal
17:11:01 <bowlofeggs> +1
17:11:04 <lruzicka> .hello2
17:11:05 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:11:20 <lruzicka> sorry about being late, was feeding dog
17:11:38 <mboddu> ack
17:12:34 <adamw> #agreed 1592686 - RejectedBlocker (Beta) - this only affects passworded VNC, and the criterion doesn't require that to work, just 'VNC'. which does work
17:12:44 <adamw> #topic (1596540) RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline
17:12:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1596540
17:12:44 <adamw> #info Proposed Blocker, dnf, ASSIGNED
17:12:50 <adamw> so...this one has a bit of a history.
17:13:31 <adamw> it was originally accepted as a blocker. that was shortly after https://bugzilla.redhat.com/show_bug.cgi?id=1596540#c30 , which suggested dmach (dnf dev) had a clear reproducer and would be able to fix the bug
17:13:38 <adamw> the bug then just sat there for a few weeks
17:13:59 <adamw> when we followed up with dnf folks, it turns out they actually *don't* have a clear reproducer and are quite baffled as to how this happened.
17:14:12 <adamw> see https://bugzilla.redhat.com/show_bug.cgi?id=1596540#c36
17:15:01 <mattdm> Yeah, I can't reproduce and I tried a lot of things
17:15:09 <adamw> i sent out an email asking for folks who are still having this issue or any other history-related dnf 3 crasher to reply, and didn't get much
17:15:26 * nirik has not seen this hear either
17:15:30 <contyk> well, according comment 43, I'm worried that an upgrade from f28 could hit this?
17:15:42 <contyk> I haven't tried reproducing this myself, though I keep hearing about it
17:15:43 <mattdm> It's pretty clear that dnf needs to be much more robust in the face of a bad or corrupt history file
17:15:55 <mattdm> but I'm not sure that that's a blocker
17:15:57 <mboddu> I never hit that issue
17:16:02 <mattdm> contyk: I did a bunch of upgrades in containers
17:16:08 <mattdm> but not on real systems (or vms)
17:16:21 <mattdm> i tried from f28 and from older (f26)
17:16:34 <nirik> openqa does do upgrades, but probibly not with modules installed or corner cases.
17:17:02 <contyk> that modules bit is a fair point
17:17:12 <contyk> mattdm: have you tried upgrading from module-enabled f28?
17:17:12 <lruzicka> nirik: We are not testing modules in OpenQA yet
17:18:26 <adamw> mattdm: well, there's the question of how these files are becoming 'bad' or 'corrupt' in the first place
17:18:35 <adamw> since it seems apparent that whatever dnf the reporters had before was fine with it.
17:18:41 <adamw> anyhow.
17:19:00 <contyk> wasn't there a change in the history format in v3?
17:19:06 <adamw> yes. lots of them.
17:19:06 <lruzicka> adamw, the dnf team changed the structure of the database file.
17:19:11 <adamw> i know that.
17:19:18 <adamw> but it's the question of how exactly they're handling the migration
17:19:33 <lruzicka> adamw, well, that I dont know
17:19:36 <adamw> i don't think they've explained that to us, and i don't think any of us has actually looked at it in detail
17:19:37 <adamw> right.
17:19:45 <mattdm> contyk:  I can try
17:20:03 <adamw> (on my long-existing system, it seems like /var/lib/dnf/history.sqlite is in the new format, and my old files are somehow 'archived' in subdirectories, but that's as far as i've looked into it so far)
17:20:22 <contyk> mattdm: that would be great; try installing a module and see what it does :)
17:20:35 <lruzicka> adamw, I remember know, dmach told me, that the new database has been placed in a new location, so it should not interfere.
17:20:37 <nirik> I'd be inclined to say -1 blocker for beta, but +1 for final... ie, more robust handling
17:20:51 <adamw> lruzicka: hrmm.
17:21:14 <mattdm> lruzicka yeah, the history.sqlite is the new location. the history subdir with filename with the date in it is the old
17:21:23 <adamw> i think my opinion is somehow that i'm -1 on this as a specific blocker but i have a sort of spidey sense reluctance about the whole state of the dnf we have in beta currently...
17:21:48 * nirik nods.
17:22:04 <mattdm> (wheee not getting network in my container for some reason. computers are fun)
17:22:07 * bowlofeggs double nods
17:22:09 <mattdm> adamw: yes, same feeling
17:22:12 <contyk> I have a bad feeling about this one so can't really say I'm against marking it as a beta blocker; on the other hand there's currently no reproducer, apparently
17:22:38 <adamw> on the other hand, my confidence that sticking some newer dnf in it would fix all problems without creating any new ones is...not high. :P
17:22:44 <adamw> on the gripping hand, computers are fun.
17:22:45 <bowlofeggs> for this particular one, i've not seen it happen and i do have some f29 and f30 systems that have been upgraded from older releases
17:22:53 <bowlofeggs> which doesn't say much
17:23:17 <bcotton> so it sounds like we don't have a solid reason to accept it as a blocker. just a collective sense of dread
17:23:21 <nirik> I've never hit this on rawhide, but then rawhide has a newer dnf now.
17:23:44 <nirik> a sense of free floating doom.
17:23:56 <bowlofeggs> haha
17:23:58 <bowlofeggs> -1 beta blocker
17:24:41 <cmurf> if there's no reproducer, it seems reasonable even if risky to -1 blocker and get a larger test pool to understand the problem better
17:25:56 <contyk> alright, -1 beta blocker
17:26:18 <contyk> unless mattdm makes his container work and tells us it's broken with modules :)
17:26:19 <adamw> let's go back to having release names
17:26:22 <lruzicka> I agree, -1 Blocker
17:26:27 <adamw> and call this one "A Sense Of Free-Floating Doom"
17:26:36 <mattdm> contyk: well, i got phase one right.
17:27:00 <nirik> ha
17:27:22 <adamw> proposed #agreed 1596540 - RejectedBlocker (Beta) - we're all sort of worried about dnf in general and a little about this bug in particular, but as lots of people *didn't* hit it and no-one has found a clear reproducer yet, we don't feel like we can reasonably count it as a blocker at this point
17:27:23 * cmurf feels nostalgic about release names
17:27:33 <cmurf> ack
17:27:36 <frantisekz> ack
17:27:40 <lruzicka> ack
17:28:01 <mattdm> so, f28 container, installed module repo, installed a random module (stratisd fwiw), running dnf upgrade with releasever=29, in progress...
17:28:01 <mboddu> ack
17:28:28 <mattdm> warning: %triggerpostun(info-6.5-10.fc29.x86_64) scriptlet failed, exit status 1
17:28:30 <mattdm> Non-fatal <unknown> scriptlet failure in rpm package libgcc
17:28:32 <mattdm> Non-fatal <unknown> scriptlet failure in rpm package libgcc
17:28:36 <mattdm> unreleated but ugly :)
17:28:43 <bowlofeggs> ack
17:28:50 <mattdm> that all went fine. dnf history works after.
17:28:54 <mattdm> so... ack
17:28:58 <adamw> #agreed 1596540 - RejectedBlocker (Beta) - we're all sort of worried about dnf in general and a little about this bug in particular, but as lots of people *didn't* hit it and no-one has found a clear reproducer yet, we don't feel like we can reasonably count it as a blocker at this point
17:29:00 <contyk> mattdm: thanks
17:29:08 <bcotton> mattdm++
17:29:53 <adamw> #topic (1625259) RuntimeError: TransactionItem not found for key
17:29:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625259
17:29:53 <adamw> #info Proposed Blocker, dnf, ASSIGNED
17:30:02 <contyk> -1 beta blocker
17:31:29 <frantisekz> -1
17:32:44 <lruzicka> -1, it seems not to break the installation and removal ability
17:33:15 <bcotton> seems like we could reuse the text from the previous proposed blocker for this one
17:33:28 <bowlofeggs> the duplicate bug sounds worse than the bug we're discussing
17:33:32 <bowlofeggs> https://bugzilla.redhat.com/show_bug.cgi?id=1627534#c1
17:33:42 <bowlofeggs> note that zbyszek reported that it left duplicate packages in plce
17:33:53 <cmurf> c8 requests an assessment, but one isn't in bug - is an assessment available to estimate the upgrade risk?
17:33:59 <bowlofeggs> so it might not just be a harmless traceback
17:34:01 <contyk> I think you can fix that with dnf remove --duplicates or somesuch
17:34:24 <contyk> I mean it's bad but not a blocker from my point of view
17:34:41 <cmurf> if there's a work around that isn't onerous (haha reinstall!) then my inclination is -1 blocker
17:34:42 <bowlofeggs> "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated."
17:34:49 <cmurf> ^beta
17:34:50 <bowlofeggs> to me, leaving dupes means it fails that criteria
17:35:06 <bowlofeggs> i would argue it's not "appropriate" to leave dupes
17:35:16 <adamw> bowlofeggs: i have new thoughts about that
17:35:33 <adamw> bowlofeggs: i now suspect zbyszek *already had* dupes, and that may in fact have triggered the bug
17:35:37 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1627534#c3
17:35:44 <cmurf> ooo
17:35:45 <nirik> ah, makes sense.
17:35:47 <bowlofeggs> adamw: oh interesting
17:35:54 <adamw> looking carefully at the transaction log and the 'rpm -qa' output, there are *three* version of libvirt-daemon referenced. not just two.
17:36:09 * nirik is -1 blocker on this, but it adds to sense of peril.
17:36:22 <cmurf> very skilled sleuthing
17:36:28 <bowlofeggs> adamw: oh yeah good call
17:36:31 <bowlofeggs> ok i'm -1 then
17:36:57 <mboddu> I am -1 Blocker
17:36:57 <bowlofeggs> though, how'd those dupes get there - is *that* a dnf bug too :o
17:37:03 <bowlofeggs> off topic i gueass
17:37:24 <adamw> probably the old 'update crashed' or something along those lines
17:37:26 <bowlofeggs> Fedora 29 - "A Sense Of Free-Floating Doom"
17:37:28 <bowlofeggs> hahah
17:37:38 <bowlofeggs> adamw: oldest trick in the book
17:37:44 <adamw> hehe
17:38:19 <mboddu> bowlofeggs: Haha :)
17:38:32 <bowlofeggs> (it was adamw's joke ☺)
17:38:36 <adamw> proposed #agreed 1625259 - RejectedBlocker (Beta) - again this is quite worrying, but with careful analysis of zbyszek's case, we still don't believe this is affecting 'normal', criteria-covered operations, only downgrades and possibly cases where the RPM database has existing duplicate entries
17:38:43 <adamw> well, nirik's words.
17:38:44 <bowlofeggs> ack
17:38:45 <contyk> ack
17:38:51 <frantisekz> ack
17:38:51 <lruzicka> ack
17:39:01 <adamw> #agreed 1625259 - RejectedBlocker (Beta) - again this is quite worrying, but with careful analysis of zbyszek's case, we still don't believe this is affecting 'normal', criteria-covered operations, only downgrades and possibly cases where the RPM database has existing duplicate entries
17:39:07 <bowlofeggs> oh yeah, nirik++
17:39:56 <adamw> okay, you may wish to hide your breakable valuables before this next one
17:39:59 <adamw> #topic (1628525) F29 KDE Live contains old wallpaper from F28
17:39:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628525
17:39:59 <adamw> #info Proposed Blocker, f29-backgrounds, NEW
17:40:03 <adamw> SERIOUSLY EVERY GODDAMN TIME
17:40:11 <nirik> ha ha ha ha ha. only not funny
17:40:23 <frantisekz> we should move that wallpaper criteria to final :)
17:40:36 <mkolman> just wait for the obligatory once per release fwraid bug ;-)
17:40:37 * langdon wonders how badly he will get hurt if he types +1 to blocker
17:40:48 <adamw> oh, i'm +1 blocker
17:40:59 <bowlofeggs> ha
17:41:02 <adamw> purely because i intend to keep this as painful as possible until someone fixes the fking wallpaper process
17:41:10 <bowlofeggs> +1
17:41:14 <langdon> perhaps, one day, it will be the f30 wallpapers in f29
17:41:22 * nirik said he would a few years ago... and then did not.
17:41:34 <adamw> we keep tweaking the criterion to make it, like, as low as possible a bar to get over
17:41:44 <adamw> it doesn't even have to be the *right* wallpaper any more, just a *different* wallpaper
17:41:57 <contyk> hehe
17:41:59 <lruzicka> yeah, even if this is a beta, it should be distinguishable from the previous version
17:42:02 <lruzicka> +1 Blocker
17:42:09 <adamw> the idea of that was so we could do 'unstable wallpaper' and 'stable wallpaper' so even in the worst case, the betas would just have the 'unstable wallpaper' and that'd be OK
17:42:16 <Southern_Gentlem> +1
17:42:20 <adamw> only we didn't even implement *that*
17:42:22 <contyk> although like frantisekz says, I would worry about this for GA, not for beta
17:42:36 <langdon> does unstable wallpaper jitter?
17:42:41 * adamw goes and checks there are no outstanding proposals to move the criterion
17:42:56 <adamw> langdon: it also looks at you funny and is gripping a glass very tightly
17:42:58 <adamw> much like me
17:43:06 <langdon> ha
17:43:33 <nirik> sadly +1, but I will cry if this is the only reason we are blocking.
17:43:41 <Southern_Gentlem> is this the only blocker?
17:43:52 <contyk> we have one accepted
17:44:02 <cmurf> +1 blocker
17:44:41 <adamw> Southern_Gentlem: nah, we have fwraid coming up too
17:44:48 <bowlofeggs> adamw: does the glass ever shatter?
17:44:53 <contyk> +0
17:44:54 <adamw> *cracks appear*
17:45:30 <cmurf> at least the fwraid bug is badass, in that it still has us stumped 12 hours later
17:45:34 <bcotton> this isn't funny. i once destroyed a laptop by accidentally squeezing a water glass to death. ;-)
17:45:44 <mattdm> Is this only in KDE?
17:45:51 <adamw> proposed #agreed 1628525 - AcceptedBlocker (Beta) - this is a clear violation of Basic criterion "The default desktop background must be different from that of the last two stable releases" for the release-blocking KDE live image
17:45:56 <adamw> mattdm: yeah.
17:45:57 <cmurf> the wallpaper is in the category of cat pics on the internet, srsly wtf?
17:46:03 <adamw> mattdm: Workstation has the new background
17:46:10 <mboddu> adamw: Cant we just propose this wallpaper thing as FE for beta and blocker for final?
17:46:30 <adamw> mattdm: because life is awful, backgrounds don't work the same on all desktops and KDE needs to do some special further change that we don't need for the new backgrounds to show up in Workstation
17:46:31 <mboddu> So that by beta if its not done, we can ask people to work on it by final
17:46:38 <mattdm> Proposal: only block on this for Editions; drop from any non-edition blocker artifacts.
17:46:44 <mattdm> (at least for beta)
17:46:46 <adamw> mboddu: i don't see how we do that without a criteria change
17:46:52 <adamw> mattdm: whoah, that's a pretty big change right there
17:47:02 <adamw> mattdm: that's an entirely new concept for the criteria / release process
17:47:10 <adamw> right now we have the concept of 'release blocking' or not...
17:47:19 <adamw> and criteria specific to some image or edition...
17:47:26 <adamw> but no concept of 'this applies only to editions'
17:47:33 <adamw> i mean, not that we can't do that, but it's not a casual criterion tweak
17:47:46 <nirik> or stop blocking on kde, but thats also a big change
17:48:00 <mattdm> Eh, ok, I see that. The less invasive way is to say that it only blocks Workstation edition?
17:48:06 <adamw> mboddu: as the criteria stand this is a pretty non-fudgeable violation
17:48:15 <bcotton> yeah. as much as i hate that this is a blocker, changing our requirements so that it isn't is out of scope for this meeting, imo
17:48:15 <adamw> mattdm: that would be a bit more in line with what we currently have
17:48:34 <mboddu> adamw: Okay, then we have to deal with it I guess
17:48:36 <mattdm> I mean, in the interest of time, let's go with that then. I think having the entirely-new-concept is probably also good
17:48:40 <adamw> bcotton: it's something we've done before, but usually only in the style of 'tweak this criterion to cover X' or 'not cover Y' or 'move from beta to final'
17:48:46 <nirik> well, there's also Xfce on arm that has to have the new desktop (but it should)
17:49:09 <adamw> the other option is, just push this criterion to Final. i mean, pace my hatred of this perpetually broken process, there's a reasonable argument for that.
17:49:20 <cmurf> haha
17:49:24 <adamw> of course it only buys us one release and just means that for F30 no-one will notice this until Final and then we'll slip Final, but hey.
17:49:38 <langdon> you could also just have ~3 rules.. blocks wkstn; blocks server; blocks cloud^watomic^wsilverblue^wsomethingSomething
17:49:39 <mattdm> adamw: right, that seems worse
17:49:40 <adamw> nirik: yeah, I think xfce is usually okay
17:49:47 <mboddu> Based on the criteria, I am +1 Blocker, but I hate blocking the release based on a wallpaper
17:50:08 <nirik> it just uses the symlink in the desktop-compat package
17:50:16 <adamw> it's kde that's weird
17:50:28 <langdon> think instead of blocking the release because fedora is getting in touch with its artful muse
17:50:29 <bcotton> what if we table this bug and evaluate the rest? if there are other blockers, there's no harm accepting this. if it's the only blocker, then we have to make a decision
17:50:36 <lruzicka> We can punt for now, solve the rest of the bugs and if there is nothing to block, we can discuss again
17:50:43 <lruzicka> bcotton, exactly
17:50:51 <adamw> yeah, that's also an option
17:50:51 <bcotton> lruzicka you're a genius :-)
17:50:53 <nirik> don't we still have the r-pi bug also?
17:50:56 <adamw> in other words, we argue about fwraid first
17:50:59 <contyk> nirik: yes
17:50:59 <adamw> nirik: rc2 should've fixed that
17:51:07 <adamw> if it even finished building yet
17:51:19 <adamw> but yeah, it'll come up in 'accepted blockers', since that's what it is
17:51:24 <mboddu> nirik: RC2 should fix the r-pi3 bug
17:51:28 <nirik> yes, I know
17:51:48 <nirik> but we don;'t even really have that yet. ;)
17:52:13 <mattdm> I have a different meeting I need to go to. burn fwraid with fire.
17:52:20 <adamw> so, yeah, that's worth flagging up: we're gonna struggle to be Go in this meeting even if we wind up with no new blockers, given that the thing we'd want to ship doesn't even exist yet.
17:52:30 <contyk> yep
17:52:45 <adamw> anyhow, shall we go with the 'run through the other bugs then come back to this' idea?
17:52:50 <contyk> yes
17:52:52 <bcotton> yes
17:52:58 <frantisekz> yep
17:53:07 <adamw> #info we're going to postpone discussion on this bug and whether to propose a criterion change till after we've been through the others
17:53:19 <adamw> #topic (1626932) Error getting active session: No data available
17:53:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626932
17:53:19 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:53:21 <adamw> -1, simple one.
17:53:25 <frantisekz> -1
17:53:45 <cmurf> -1
17:53:53 <adamw> the actual error message is i think just an artifact of shutdown order (vdagent is unhappy for a short time while the session is shutting down), 'it logs out a bit slower than before' is not a blocker issue.
17:54:12 <nirik> -1 blocker
17:54:20 <contyk> -1
17:54:34 <bowlofeggs> -1
17:55:17 <mboddu> -1 Blocker
17:55:49 <adamw> proposed #agreed 1626932 - RejectedBlocker (Beta) - the state of this issue with Beta RC1 as described in comment #7 clearly doesn't violate any criteria
17:55:56 <contyk> ack
17:55:57 <frantisekz> ack
17:56:03 <nirik> ack
17:56:20 <mboddu> ack
17:56:25 <bowlofeggs> ack
17:56:27 <adamw> #agreed 1626932 - RejectedBlocker (Beta) - the state of this issue with Beta RC1 as described in comment #7 clearly doesn't violate any criteria
17:56:28 <lruzicka3> ack
17:56:45 <adamw> #topic (1628497) gnome-software shows upgrade banner for Fedora 28 instead of Fedora 29
17:56:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628497
17:56:45 <adamw> #info Proposed Blocker, gnome-software, NEW
17:56:49 <contyk> if I understand this correctly, it's just about gnome-software, not upgrades being broken in general
17:56:52 <contyk> so -1
17:56:55 <adamw> yeah
17:57:05 <adamw> well
17:57:24 <adamw> note the footbote
17:57:26 <adamw> footnote
17:57:31 <adamw> "This criterion applies to the recommended upgrade mechanisms only."
17:57:39 <adamw> with a link to https://fedoraproject.org/wiki/Upgrading
17:57:54 <adamw> which specifically recommends the GNOME Software upgrade for Workstation
17:58:02 <contyk> does it mean that all of them have to be working?
17:58:30 <cmurf> *direct upgrade*
17:58:36 <adamw> i'd say it means that for each release-blocking edition/image/whatever, the recommended upgrade method for that edition/image/whatever should work.
17:58:43 <lruzicka3> adamw, maybe we should redefine the criteria, because it is much worse if the upgrade banner points to a wrong version than an old wallpaper
17:58:56 <contyk> :)
17:58:56 <cmurf> does that mean F27 -> F29, rather than intermediate upgrade which is F27->F28->F29 which is essentially what's on offer?
17:59:07 <adamw> cmurf: yes.
17:59:24 <adamw> we had a debate about which one g-s should offer, and the verdict was, direct upgrade.
17:59:28 <nirik> hum... this would mean we don't get testing of this upgrade method
17:59:40 <nirik> but we could hopefully fix it in an upgrade.
17:59:43 <cmurf> my memory is fuzzy but i'm pretty sure Workstation WG explicitly wanted direct upgrades, but I'm not sure if it was intended to block beta or final
18:00:00 <adamw> note if we accept this it'd in all likelihood be an AcceptedPreviousReleaseBlocker
18:00:10 <adamw> meaning it doesn't block the f29 compose, but rather it must be fixed in f27 by f29 release daty
18:00:16 * frantisekz will be away for ~30 mins
18:00:17 <cmurf> gotcha
18:00:36 <cmurf> what are the chances of that?
18:00:48 <adamw> getting it fixed? dunno
18:00:52 <adamw> don't think we know what the problem is, yet
18:00:58 <contyk> what happens if it's not fixed by that date?
18:01:02 <adamw> i'd be interested in what happens if you drop f28 from the cached collections json entirely
18:01:11 <adamw> contyk: ...fire
18:01:20 <cmurf> fines
18:01:22 <cmurf> massive fines
18:01:59 * nirik ponders
18:02:44 <adamw> contyk: https://www.penny-arcade.com/comic/2009/06/17
18:02:45 * sgallagh had another meeting, but is here now.
18:03:10 <cmurf> clearly we need f27 to f29 upgrades to work for final, and to know that we need to be able to test it. So at some point soon after beta is public, we need an update to fix F27.
18:03:17 <adamw> hey, we traded a mattdm for an sgallagh
18:03:32 <sgallagh> Unsurprisingly, we had 1x1 meetings with the same person :-P
18:03:33 <nirik> so I guess I am a weak +1 to PreviousReleaseBlocker
18:04:02 <contyk> it feels kinda pointless but +1
18:04:11 <cmurf> I'm in that same boat, weak +1 previous release blocker
18:04:12 <adamw> i'd be willing to be -1 if we can figure a workaround
18:04:18 <adamw> like...removing f28 from the collections json...
18:04:26 <adamw> hold on a sec, i have an f27 system here, let me poke it a bit.
18:05:13 <cmurf> okilly dokilly
18:05:22 <adamw> i've *warned* you
18:06:05 <lruzicka3> adamw, isn't a workaround, if users upgrade to 28 and then to 29 from 27? it is easy, straightforward, they do not have to delete anything ...
18:06:31 <cmurf> heat death
18:06:32 <lruzicka3> and it will be super safe
18:06:35 <adamw> lruzicka3: but the agreement was that we should test and support, and GNOME should offer, *direct* upgrades
18:06:51 <mboddu> adamw: +0.5 PreviousReleaseBlocker
18:06:54 <adamw> that's what the criteria say
18:07:17 <adamw> and if this is about stable vs. unstable (gnome-software prefers showing stable over unstable), then that would be bad, because we'd test f27-f28-f29 all through development
18:07:25 <lruzicka3> adamw, so let's block then. I am only saying that fiddling with a json file is not a workaround for everybody
18:07:29 <adamw> but as soon as f29 went stable, f27 g-s would start offering direct upgrade to f29 instead of intermediate upgrade to f28
18:07:33 <jforbes> I can see the need there. Realistically telling users to upgrade twice is lame, and improves the room for error, are we testing that upgrade path with current packages?
18:07:35 <adamw> which we wouldn't have tested at all
18:07:37 <bowlofeggs> +1 previous release blocker, given that criteria
18:07:43 <adamw> lruzicka3: but it's a workaround for beta users.
18:07:59 <adamw> jforbes: we kinda decided the whole 'which one is safer' thing is a bit 'six of one, half a dozen of the other'
18:08:14 <adamw> there are different plausible cases where each would work better
18:08:18 <adamw> so we just had to pick one
18:08:40 <lruzicka3> adamw, ok, beta users should be able to deal with it, I agree
18:08:51 <jforbes> adamw: right, so if it isn't safer, why make it more difficult? (Not that I am suggesting this block beta)
18:08:55 <cmurf> i'm fine with the criterion as it is, as long as it's going to compel discovering and fixing the problem in f27, rather than holding up f29 for something that f29 can't even fix
18:10:57 <sgallagh> cmurf: +1
18:11:25 <x3mboy> .hello2
18:11:26 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
18:12:36 <cverna> what about people that want to upgrade to f28 from f27 ? would that not be available in gnome software ?
18:12:45 <sgallagh> For the record, does anyone disagree and feel that we should block F29 on this?
18:12:57 <nirik> cverna: sure it is... just don't enable prereleases.
18:12:59 <sgallagh> If not, we can probably punt this discussion
18:13:09 <cverna> I think some users like to stay a release behind
18:13:13 <adamw> i'm just on the fence about whether to even make it a previous release blocker, if we can figure a workaround. for final, sure
18:13:15 <cverna> nirik: ah ok
18:13:18 <nirik> sgallagh: we are waiting for adamw to test.
18:13:25 <sgallagh> nirik: I think cverna means once F29 is out
18:13:29 <adamw> ok, i managed to get f29 to show up by editing the json
18:13:34 * nirik plays elevator music
18:13:36 <adamw> so i'm gonna say -1 beta +1 final previousrelease blocker
18:13:48 <sgallagh> cverna: That's not supported from GNOME Software.\
18:13:51 <adamw> i think for beta it's ok to say 'use dnf or hack the json to test'. we should fix it for f27 asap though of course
18:13:55 <nirik> ah, yeah, there's not a way unless you edit the json file I don't think.
18:13:56 <sgallagh> You can do it with dnf though
18:14:07 <sgallagh> adamw: +1
18:14:18 <nirik> ok. I can agree with that if there's a workaround.
18:14:20 <cverna> sgallagh: ok thanks for the answer :)
18:15:27 <adamw> other votes?
18:15:39 * sgallagh can vote +1 multiple times if you like
18:15:51 <lruzicka3> -1
18:15:58 <x3mboy> +1 from the marketing side. Clarifying that it would be fixed for GA
18:16:05 <sgallagh> lruzicka3: What are you voting -1 on?
18:16:28 <lruzicka3> against this bug to be an F29 beta blocker
18:16:42 <sgallagh> OK, maybe we should phrase the proposal more clearly :)
18:17:14 <cmurf> +1 fix F27 ASAP "previous release blocker"
18:17:15 <adamw> ok, so, the options are: PreviousReleaseBlocker for Beta, or PreviousReleaseBlocker for Final
18:17:22 <adamw> please vote +1/-1 on both of those
18:17:26 <cmurf> OIC
18:17:44 <lruzicka3> -1 PRB Beta, +1 PRB Final
18:17:46 <sgallagh> adamw: +1 PreviousReleaseBlocker for Final, -1 PreviousReleaseBlocker for Beta
18:17:46 <nirik> -1 beta blocker, +1 PreviousReleaseBlocker for final
18:17:50 <adamw> my vote is -1 Beta PRB, +1 Final PRB
18:18:05 <cmurf> -1 beta PRB, +1 final PRB
18:18:05 <x3mboy> -1 beta blocker, PRB for final +1
18:18:40 <bowlofeggs> -1 beta, +1 final
18:20:27 <mboddu> -1 beta, +1 final blocker
18:20:31 <adamw> proposed #agreed 1628497 - RejectedBlocker (Beta), AcceptedPreviousReleaseBlocker (Final) - as there are viable workarounds (use dnf, go through F28 first, hack up the cached JSON...) we believe those are sufficient for Beta, but this counts as a violation of the upgrade criterion for Final and must be fixed in F27 prior to F29 release
18:20:36 <mboddu> ack
18:20:43 <contyk> ack
18:21:05 <lruzicka3> ack
18:21:16 <nirik> ack
18:21:22 <adamw> #agreed 1628497 - RejectedBlocker (Beta), AcceptedPreviousReleaseBlocker (Final) - as there are viable workarounds (use dnf, go through F28 first, hack up the cached JSON...) we believe those are sufficient for Beta, but this counts as a violation of the upgrade criterion for Final and must be fixed in F27 prior to F29 release
18:21:44 <adamw> ok, here comes the other fun one
18:21:45 <adamw> #topic (1628192) Fedora 29 installation cannot see a firmware RAID device.
18:21:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628192
18:21:45 <adamw> #info Proposed Blocker, mdadm, NEW
18:22:10 <adamw> i've been poking at this for a day and a half and it's still confusing me. but as the criteria stand it clearly violates them
18:22:24 <adamw> we've tested on two different Intel firmware raid boxes, both fail the exact same way
18:23:13 <nirik> sadly +1 blocker (but we should look at removing the firmware raid criteria IMHO)
18:23:22 <adamw> there *is* a workaround, as noted in the bug, though it's not obvious (you'd have to know quite a lot about mdraid or read docs)
18:23:25 <sgallagh> I'd propose that we vote to remove this criterion
18:23:46 <cmurf> I agree
18:23:54 <sgallagh> It's relatively rare to encounter someone who both has this hardware feature AND is actually using it.
18:24:08 <cmurf> we're having difficult finding people with this feature, and willing to test a pre-beta
18:24:13 <contyk> well, I don't think this meeting is about changing the criteria
18:24:13 <sgallagh> Because most of the people who would actually do a RAID setup are people who know how to do it properly.
18:24:16 <contyk> +1 to blocker
18:24:32 <sgallagh> contyk: We've made decisions like this before
18:24:36 <adamw> sgallagh: that seems like a loaded definition.
18:24:44 <adamw> there are reasons to choose firmware raid over kernel raid.
18:24:47 <sgallagh> adamw: Well, I wasn't defining it.
18:24:57 <adamw> what did you mean by 'properly', then?
18:25:12 <sgallagh> adamw: either kernel RAID or dedicated hardware controller
18:25:20 * nirik doesn't see any reason to use firmware raid, but could be just me
18:25:30 <cmurf> well arguably firmware raid used to be more common with the dual booters because it's firmware initiated raid, only meaning the firmware sees the array rather than member devices
18:25:31 <bowlofeggs> +1 blocker
18:25:42 <cmurf> and it's the driver on Windows and Linux that does the actual raid
18:26:13 <cmurf> but again hard to test with diminishing numbers with this hardware feature
18:26:29 <cmurf> I'm -1 beta blocker, and +1 moving it to final
18:26:37 <sgallagh> I'm also opposed to having a blocking criterion that we generally don't/can't test.
18:26:58 <adamw> lruzicka3: is there a reason we didn't test this earlier?
18:27:00 * sgallagh feels the same about SAS
18:27:01 <bowlofeggs> i don't oppose changing the criteria, but i do think this is a clear +1 if we don't change the criteria
18:27:02 <cmurf> there's no advantage having this criterion apply for beta, there might be a weak argument having it for final
18:27:12 <cmurf> bowlofeggs: correct
18:27:29 * cmurf feels the same about IDE/PATA
18:27:35 <sgallagh> heh
18:27:42 <lruzicka3> adamw, well, there is not .. I think that we just focused on different things - CoreOS, modularity ... and it somehow slipped
18:27:43 <adamw> sgallagh: btw, are you assuming we are going to be Go if there are no accepted blockers?
18:27:46 <adamw> because i'm not sure we are.
18:28:00 <contyk> nope
18:28:01 <adamw> lruzicka3: okay.
18:28:03 <sgallagh> adamw: No, I just don't think I'd slip for this
18:28:12 <adamw> sgallagh: okay.
18:28:37 <sgallagh> (I consider all blockers by whether I'd hold the release if it was the last one left... this is not passing that bar for me)
18:28:58 * nirik is with bowlofeggs. I'm +1 blocker on the current critera, but wouldn't mind changing that if we want to do that here.
18:29:24 <adamw> well, let's take a vote on the criteria issue, then.
18:29:24 <bowlofeggs> sgallagh: i'd think that if the criteria didn't say "firmware"
18:29:32 <adamw> three options:
18:29:36 <adamw> 1) keep criteria as they are
18:29:42 <adamw> 2) move firmware raid requirement to Final
18:29:47 <adamw> 3) remove firmware raid requirement
18:29:47 <adamw> votes?
18:29:57 <bowlofeggs> i'd +1 #2
18:30:05 <sgallagh> I'd prefer 3 but I'd be satisfied with +2
18:30:07 <contyk> changing criteria at this point feels fairly wrong to me; that should have been done earlier
18:30:11 <bowlofeggs> i'd also +1 #3
18:30:13 <mboddu> adamw: I am more towards #2, but I dont mind #3 as well
18:30:25 <Southern_Gentlem> +1 3
18:30:28 <bcotton> +1 #3, +.5 #2
18:30:29 <adamw> i'm +/-0 to all on same basis as contyk
18:30:30 <sgallagh> s/+/#/
18:30:37 <cmurf> i'm with sgallagh, I'm going to +1 #2 and if we don't get more help with testing firmware raid then at that time we can strike the firmware criterion entirely
18:30:38 <contyk> +1 #1
18:30:48 <adamw> this criterion isn't a surprise. it's been around a long time. if it was going to be changed it'd be nice if people did it outside of 'last minute in a blocker meeting.'
18:30:56 <bowlofeggs> what would be the more appropriate venue to change the criteria?
18:31:04 <lruzicka3> I am +2 now and +3 when we will have released F29
18:31:11 <adamw> bowlofeggs: the 'official' venue is 'the mailing lists', basically - test@, maybe devel@
18:31:14 <sgallagh> The problem is, we never really notice that it's there until something triggers it
18:31:26 <contyk> we can change the criteria for the next release
18:31:27 <adamw> the usual process is to send out a draft proposing a change, then consider feedback
18:31:37 <adamw> it's a loose-consensus type thing
18:31:39 <contyk> and not just to push something that's broken
18:31:42 <cmurf> adamw: we've loosly pondered this for several releases because it does tend to pop up at the last minute due to lack of test hardware
18:31:48 * nirik is +1 to 3 and a weak +1 to 2.
18:31:49 <lruzicka3> adamw, we can also remember to make this one the very first thing to test
18:31:54 <sgallagh> Proposal: Treat this as a Final Blocker for F29, propose dropping it for F30+
18:32:01 <adamw> sgallagh: firmware RAID bugs have come up before, though. multiple times. that would've been a sufficient prompt for you to think about proposing a change for the next cycle.
18:32:26 <adamw> cmurf: we specifically ensure brno has a system with fwraid specifically for testing this
18:32:38 <mboddu> adamw: I want to propose #4, move raid support to FE rather than blocker
18:32:38 <adamw> just...no-one actually *did* it for any of the earlier validation composes, this cycle
18:32:47 <adamw> mboddu: that'd be effectively #3
18:33:07 <adamw> so, let me count votes
18:33:11 <lruzicka3> mboddu, if nobody wants to push an update, then FE does not help mucnh
18:33:13 <lruzicka3> much
18:33:33 <mboddu> lruzicka3: True, but its good to track it even though we dont block on it
18:33:52 <adamw> we have six votes for Change, one vote for Stay The Same, one abstention
18:34:12 <adamw> mboddu: neither blocker nor FE processes are for 'tracking', that is a personal bugbear of mine :)
18:34:13 <cmurf> i think it's far less controversial to move the requirement to final, than to abandon the requirement entirely
18:34:17 <adamw> if you want a tracker bug for tracking, make one. :P
18:34:28 <adamw> so, i'm gonna propose this:
18:35:46 <mboddu> adamw: Okay :)
18:35:59 <adamw> proposed #agreed 1628192 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is a fairly clear violation of the criteria as written (though with a workaround), but there is substantial support for either moving the firmware RAID criterion to Final or removing it entirely. On that basis this is rejected as a blocker, and we will propose some options for revising the criteria on the mailing list, on the expectation that at minimum the Beta
18:35:59 <adamw> requirement for this will no longer exist.
18:36:02 <adamw> sigh
18:36:24 <bowlofeggs> +1
18:36:34 <cmurf> +1 and ack
18:36:43 <adamw> proposed #agreed 1628192 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is a fairly clear violation of the criteria as written (though with a workaround), but there is substantial support for either moving the firmware RAID criterion to Final or removing it entirely. On that basis this is rejected as a blocker, and we will send some criteria proposals to the list, expecting at least that the Beta requirement will no longer exist.
18:36:50 <contyk> I'd like to see this as a beta blocker and move the discussion about this criterion to the list (and I'd like to keep it as is, personally)
18:36:59 <contyk> but I'm alone in this, so ack, I guess
18:37:02 <adamw> contyk: noted, but yours is the only clear vote for that
18:37:07 <adamw> i abstained, everyone else voted For Change
18:37:08 <adamw> :P
18:37:11 <mboddu> ack
18:37:14 <cmurf> ROFL
18:37:23 <lruzicka3> ack
18:37:24 <adamw> contyk: as per tradition, this gives you the Sacred Right To Say I Told You So
18:37:26 <adamw> use it wisely
18:37:27 <nirik> ack.
18:37:33 <sgallagh> ack
18:37:34 <contyk> :P
18:37:36 <mboddu> sorry contyk
18:37:59 <nirik> and contribute to a 'lively' mailing list discussion about changing the critera. ;)
18:38:06 <adamw> i get the Not-So-Sacred Right To Stand Behind Contyk Looking Vaguely Virtuous But Not Pushing It Too Far
18:38:22 * cmurf knows the truth adamw
18:38:25 <sgallagh> For the record, I think we should probably slip one week for reasons of "polish", which gives time for this to also be fixed. I just don't think that if we get to Go/No-Go again in a week and this was the last bug standing that I'd let it stop us.
18:38:32 <adamw> #agreed 1628192 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is a fairly clear violation of the criteria as written (though with a workaround), but there is substantial support for either moving the firmware RAID criterion to Final or removing it entirely. On that basis this is rejected as a blocker, and we will send some criteria proposals to the list, expecting at least that the Beta requirement will no longer exist.
18:38:37 <mboddu> contyk: You can still fight for it being a final blocker :)
18:39:00 <adamw> #info now doing the sole accepted blocker before circling back to the KDE backgrounds thing
18:39:09 <adamw> #topic (1628355) F29 Beta RC1 does not boot on Raspberry Pi
18:39:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628355
18:39:09 <adamw> #info Accepted Blocker, spin-kickstarts, NEW
18:39:25 <contyk> so supposedly fixed in RC2 which doesn't exist yet?
18:39:32 <mboddu> adamw: Which should be fixed in RC2
18:39:37 <adamw> so, the status here is: this was a bug in RC1. according to pbrobinson / pwhalen, Beta RC1 32-bit ARM images will not boot on raspberry pis at all
18:39:40 <mboddu> contyk: right
18:39:54 <adamw> we accepted this as a blocker out-of-band and fired RC2 to fix it
18:39:54 * mboddu wonders if it completed making the arm images
18:39:58 <sgallagh> Just to confirm, both Pi2 and Pi3 are blocking, right?
18:40:06 <adamw> sgallagh: yup.
18:40:17 <nirik> mboddu: I think not yet, it's doing lives and arm images are right after that
18:40:17 <sgallagh> ok
18:40:19 <adamw> pi3 probably works with 64-bit images, but pi2 doesn't have that option
18:40:28 <adamw> Beta RC2 is not yet complete
18:40:30 * sgallagh notes that the aarch64 worked fine... yeah
18:40:41 <adamw> so, as of right now, we don't have this fixed. but it is expected to be fixed when RC2 finishes.
18:40:42 <sgallagh> This is worth slipping on.
18:40:51 <contyk> expected, yeah
18:40:57 <contyk> but currently isn't
18:41:03 <adamw> there's not much for this meeting to do at this point, just recording the status.
18:41:23 <cmurf> ETA?
18:41:28 <sgallagh> I recommend we slip a week. No "hero testing", please.
18:41:34 <adamw> #info this bug meant Beta RC1 32-bit ARM images do not boot on Raspberry Pi. Pi2 and Pi3 are supported platforms. Beta RC2 should fix this, but it is still composing at present and so has not been tested at all yet.
18:41:37 <adamw> sgallagh: that comes in a minute
18:41:42 <sgallagh> There's a bunch of other FEs that would be really nice to get in if we slip anyway
18:41:48 <adamw> #info circling back to KDE backgrounds blocker
18:41:50 * sgallagh nods
18:42:01 <adamw> #topic (1628525) F29 KDE Live contains old wallpaper from F28
18:42:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628525
18:42:01 <adamw> #info Proposed Blocker, f29-backgrounds, NEW
18:42:06 <adamw> so, we said we'd hold this for later, and it's later. =)
18:42:20 <bcotton> might as well accept it since it looks like we're a no-go anyway
18:42:28 <adamw> we didn't accept any other blockers, so this would technically be the only unaddressed blocker if it is accepted.
18:42:36 <adamw> that's a terrible reason to vote +1, and i agree with it.
18:42:37 <nirik> +1 blocker, but sad...
18:42:42 <sgallagh> This is another one of those things I wouldn't block on if it was the last one at Beta
18:42:52 <sgallagh> adamw: No, the Pi2 issue is still unaddressed
18:42:55 <mboddu> sgallagh: No "hero testing", please - I agree
18:43:22 <adamw> sgallagh: eh, it's 'addressed' in that the fix was committed and the compose is running.
18:43:49 <bcotton> but it's schrodinger's fix until the compose is done and tested
18:43:52 <nirik> right, but we still need to test it... and retest other things? or assuming we can just pull results from rc1?
18:43:57 <sgallagh> bcotton: That ^^
18:45:07 <bcotton> so we're 15 minutes until the release readiness meeting. adamw, do you want to take a moment and report on the status of the tests, or can we just skip to a final vote on status?
18:45:26 <sgallagh> We should finish this blocker proposal first
18:45:38 <bowlofeggs> +1 from me, also has sad
18:45:40 <bcotton> sgallagh: good point
18:45:56 <adamw> sgallagh: are you a -1 on this?
18:46:12 <sgallagh> I'm -1 blocker, +1 FE mostly because as I said, I'd fight tooth and nail about blocking Beta *just* for this
18:46:18 <adamw> okay.
18:46:33 <adamw> so we have...bcotton, me, nirik, bowlofeggs +1, sgallagh -1
18:46:34 <adamw> any other votes?
18:46:40 <lruzicka3> -1 for Blocker
18:46:40 <sgallagh> GA I could see.
18:46:42 <contyk> +0
18:46:51 <adamw> oh good, a split decision
18:46:58 <bowlofeggs> haha
18:46:59 <mboddu> +1 Blocker
18:47:01 <contyk> adamw: I have your back, more or less...
18:47:04 <adamw> lruzicka3: sgallagh: do you have a criteria change proposal for us?
18:47:05 <contyk> adamw: in the distance
18:47:13 <adamw> +4, -2
18:47:14 <mboddu> Based on the criteria, unless we change it
18:47:40 <lruzicka3> I think, we should change the criteria, when possible.
18:47:47 <cmurf> -1 blocker, +1 FE
18:47:47 <adamw> i love how we're all anticipating future choices in this meeting while discussing this. i feel like we're doing politics!
18:47:53 <adamw> +4, -3
18:47:56 <sgallagh> adamw: I swear I've proposed to drop this criteria in the past and heard crickets
18:48:03 <mboddu> Also, I dont think we should go for a release next week even if we decide to consider this as a non blocker
18:48:04 <adamw> sgallagh: i was looking, but didn't see anything
18:48:12 <adamw> (in the archives)
18:48:34 <sgallagh> adamw: I'd move this from being a Beta blocker to a guaranteed +1 FE and a GA Blocker
18:48:48 <lruzicka3> mboddu, I believe, we need time to test RC2
18:48:59 <adamw> okay, new idea
18:49:39 <adamw> i propose we leave this bug's blocker status undetermined, do the test status quickly, then make the go/no-go decision with this bug's status undetermined
18:49:49 <lruzicka3> I think that sgallagh's idea is good, but I also understand those relying on the criteria.
18:49:49 <bcotton> +1
18:49:53 <nirik> hum.
18:49:57 <mboddu> lruzicka3: Yes, just dont want to raise the hopes of the people assuming there will be a release next week if there are no blockers
18:50:09 <contyk> -1
18:50:24 <adamw> contyk: well i dunno what else to do
18:50:32 <adamw> as we can't really accept or reject the bug with votes of +4, -3
18:50:33 <contyk> adamw: give it a week
18:50:38 <sgallagh> mboddu: I'd recommend we slip anyway, as I said. I don't think what's left are individually blockers, but taken as a whole... there's a lot of easy polish we can do in a week
18:50:48 <adamw> so i'm anticipating the general mood that we want to slip for other reasons
18:50:54 <adamw> meaning we wouldn't *have* to decide on this bug's status right now
18:51:12 <contyk> adamw: I think we need more time for testing RC2
18:51:16 <adamw> right.
18:51:18 <mattdm> we're not slipping! we're opting to use the scheduled-in Target #1 instead of Target #0
18:51:20 <sgallagh> adamw: At minimum, shall we accept it as +1 FE so they can get it in if we slip?
18:51:22 <contyk> adamw: not just "do it quickly" and declare go
18:51:22 <adamw> but technically we make that call after the blocker review.
18:51:27 <nirik> mattdm++
18:51:28 <zodbot> nirik: Karma for mattdm changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:51:29 <adamw> sgallagh: sure.
18:51:30 <adamw> is anyone -1 FE>
18:51:31 <mattdm> that's for phoronix :)
18:51:31 <adamw> ?
18:51:34 <cmurf> good point mattdm
18:51:44 * adamw gets out the cosh and looks for the phoronix spy
18:51:47 <sgallagh> mattdm++
18:51:48 <zodbot> sgallagh: Karma for mattdm changed to 11 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:51:59 <bowlofeggs> adamw: it's been me all along, muahahah!
18:52:00 <mboddu> sgallagh: I agree, and we can punt the decision on this to next week and if its the only blocker remaining then I will vote for +1 FE
18:52:06 <lruzicka3> no, I am +1 FE
18:52:10 <bowlofeggs> +1 FE
18:52:14 <cmurf> i admit I'm conflating two things in my vote: the criterion as it stands means it's a blocker
18:52:17 <nirik> I think we can all be +1 FE... that should be easy
18:52:31 <adamw> proposed #agreed 1628525 - AcceptedFreezeException (Beta) - we do not have a clear vote on blocker status for this bug (the vote was +4, -3). but we have consensus that it should at least be a freeze exception. we will proceed with the meeting with its blocker status undecided
18:52:35 <bcotton> +1
18:52:39 <cmurf> ack
18:52:46 <sgallagh> adamw: ack
18:53:00 <contyk> ack
18:53:14 <adamw> #agreed 1628525 - AcceptedFreezeException (Beta) - we do not have a clear vote on blocker status for this bug (the vote was +4, -3). but we have consensus that it should at least be a freeze exception. we will proceed with the meeting with its blocker status undecided
18:53:15 <nirik> man, we do weird things at our meetings. ;)
18:53:15 <adamw> OK
18:53:28 <adamw> shhhhhh
18:53:29 <adamw> this is all fine
18:53:34 <cmurf> everything is fine
18:53:35 <mboddu> nirik: hahahah :D
18:53:40 <nirik> this is fine.
18:53:50 <adamw> bcotton: ok, that's all the blockers, do you want to take back control?
18:54:04 <bcotton> got it
18:54:19 <bcotton> #topic Current status - tests
18:54:29 <bcotton> adamw: can you give the status of tests in 20 words or less?
18:54:34 <bcotton> fewer*
18:54:41 <adamw> no
18:54:43 <adamw> but i'll try!
18:54:47 <bowlofeggs> (this is fine)
18:55:10 <mboddu> adamw: Yes, you can, there are "none" as rc 2 is still running :P
18:55:51 <adamw> #info validation coverage is actually pretty good for RC1 (which still has the known ARM blocker). I see only a couple of missing tests (hardware RAID, 'basic audio'). There is no validation coverage at all for RC2 yet. Difference between RC1 and RC2 is minimal so we could consider most RC1 testing valid against RC2, but we should really at least smoke-test RC2 and check the ARM images boot on raspbi
18:55:54 <sgallagh> adamw: You have 16 words left
18:55:54 <adamw> er
18:55:58 <sgallagh> d'oh, late
18:56:00 <adamw> #undo
18:56:00 <zodbot> Removing item from minutes: INFO by adamw at 18:55:51 : validation coverage is actually pretty good for RC1 (which still has the known ARM blocker). I see only a couple of missing tests (hardware RAID, 'basic audio'). There is no validation coverage at all for RC2 yet. Difference between RC1 and RC2 is minimal so we could consider most RC1 testing valid against RC2, but we should really at least smoke-test RC2 and check the ARM images boot on raspbi
18:56:04 <adamw> #info validation coverage is actually pretty good for RC1 (which still has the known ARM blocker). I see only a couple of missing tests (hardware RAID, 'basic audio'). There is no validation coverage at all for RC2 yet. Difference between RC1 and RC2 is minimal so we could consider most RC1 testing valid against RC2, but we should really at least smoke-test RC2 and check the ARM images boot on rasbpi
18:56:42 <adamw> i would also say that i personally am a little nervous about the 'test status' from a wider PoV
18:57:33 <sgallagh> Yeah, I'm also not comfortable with RC2 not having been tested at all
18:57:40 <adamw> yes we got through most of the RC1 validation, but we haven't really had the bits very long for more freeform testing, and i'm generally worried about the state of DNF especially, would like to check on what the status of dbus is, have a bit more time to bash on GNOME 3.30, stuff like that
18:57:56 <lruzicka3> adamw, I did basic audio, it worked. I am not sure whether I recorded it or not
18:58:09 <cmurf> our deterministic computers product non-determinstic results :P
18:58:10 <adamw> lruzicka3: ah, it's not in testcase_stats yet. might just show up on the next hourly refresh
18:58:20 <bcotton> well it sounds like we may end up with an RC3 given the new target and the FEs we have approved
18:58:38 <adamw> anyway, that's test coverage
18:58:43 <bcotton> okay, great
18:58:56 <bcotton> so let's make it formal then
18:59:06 <bcotton> #topic Go/No-Go decision
18:59:08 <bcotton> I will poll each team. Please reply “go” or “no-go”
18:59:10 <bcotton> FESCo
18:59:14 <sgallagh> no-go
18:59:16 <nirik> no-go
18:59:17 <contyk> no-go
18:59:22 <bcotton> RelEng
18:59:40 <adamw> mboddu, you're up :P
18:59:43 * nirik waits for mboddu, but also chimes in again no-go with another hat
18:59:51 <bcotton> works for me
18:59:51 <mboddu> no-go
18:59:54 <bcotton> QA
19:00:05 * sgallagh peers at nirik. Eh, must be his twin brother.
19:00:25 <x3mboy> no-go
19:00:36 <adamw> by QA policy, i believe our vote must be no-go as there has been no testing of RC2 at all
19:00:42 <lruzicka3> nogo
19:00:46 <bcotton> #agreed Fedora 29 is NO-GO
19:00:47 <bcotton> #info The next F29 Beta Go/No-Go meeting will be Thursday, 2018-09-20 at 1700 UTC
19:00:53 <bcotton> #action bcotton to announce decision
19:00:53 <adamw> personally i also agree with sgallagh that we should take a week to polish several things
19:01:14 <bcotton> everyone is welcome to stick around in this channel for the release readiness meeting which starts one minute ago
19:01:21 <bcotton> otherwise, i'll see you next week!
19:01:22 <adamw> =)
19:01:25 * adamw grabs his tardis
19:01:27 <contyk> wonder how many beta blockers we'll get from rc2
19:01:30 <bcotton> #endmeeting