17:00:24 <adamw> #startmeeting F30-blocker-review
17:00:24 <zodbot> Meeting started Mon Dec 17 17:00:24 2018 UTC.
17:00:24 <zodbot> This meeting is logged and archived in a public location.
17:00:24 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:24 <zodbot> The meeting name has been set to 'f30-blocker-review'
17:00:24 <adamw> #meetingname F30-blocker-review
17:00:24 <zodbot> The meeting name has been set to 'f30-blocker-review'
17:00:24 <adamw> #topic Roll Call
17:00:35 <adamw> morning folks! who's around for some exciting f30 blocker review funtimes?
17:00:43 * coremodule is present and willing to secretarialize!
17:00:51 <adamw> (the management reserves the right to define "exciting" and "fun")
17:01:06 <bcotton> .hello2
17:01:07 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:01:09 * satellit listening
17:01:12 * jlanda is present and with connectivity issues as always :D
17:01:49 <lruzicka2> .hello lruzicka
17:01:50 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:04:50 <adamw> welp, guess that's the lot
17:05:02 <adamw> #chair coremodule lruzicka2
17:05:02 <zodbot> Current chairs: adamw coremodule lruzicka2
17:05:10 <adamw> boilerplate incoming!
17:05:12 <adamw> #topic Introduction
17:05:12 <adamw> Why are we here?
17:05:12 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:05:12 <adamw> #info We'll be following the process outlined at:
17:05:14 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:05:14 <adamw> #info The bugs up for review today are available at:
17:05:18 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:05:20 <adamw> #info The criteria for release blocking bugs can be found at:
17:05:22 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:05:24 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria
17:05:26 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria
17:05:31 <adamw> #info for Beta, we have:
17:05:32 <adamw> #info 4 Proposed Blockers
17:05:36 <adamw> #info 2 Proposed Freeze Exceptions
17:05:38 <adamw> #info for Final:
17:05:45 <adamw> #info 3 Proposed Blockers
17:06:00 <adamw> #info getting started with proposed Beta blockers
17:06:05 <adamw> #topic (1653059) after upgrade dbus to 1.12.10-9 system hang and couldn't boot after reboot
17:06:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1653059
17:06:05 <adamw> #info Proposed Blocker, dbus, NEW
17:06:55 <adamw> so, i'm not 100% sure where we are with the dbus stuff atm
17:07:03 <adamw> but openqa upgrade tests don't seem to have this issue, at least
17:07:18 * jlanda hopes to be wrong but I feel that dbus & bootloader will be recurrent stuff on this cycle
17:08:03 <adamw> we'll have to see.
17:08:11 <jlanda> I made a fast test today and haven't reproduced it but it would be good to know what happens on some other scenarios, I just run a standard qemu test
17:08:27 <adamw> the openQA upgrade tests are also working, as in the system actually upgrades and the upgraded system works
17:08:40 <adamw> i haven't looked in detail into the exact status of dbus-daemon and dbus-broker after the upgrade
17:09:00 <adamw> i suspect this is *basically* fixed now, at least as far as 'upgrade from f29 to rawhide doesn't completely mess up'
17:09:51 <jlanda> we should try 28->30 too, this is a sensible piece of software
17:10:20 <coremodule> Under what criteria would this fall? In the original post by Mikhail, it's stated as "...completely broke the system..."
17:10:33 <adamw> jlanda: openQA does that too.
17:10:40 <jlanda> Oh, good to know ;)
17:10:47 <adamw> coremodule: the upgrade criteria require that the upgraded system meet all the other criteria
17:10:58 <adamw> so you could've picked any old one - 'installed system must boot to the login screen' or whatever
17:11:08 <jlanda> coremodule: upgraded system should work blablabla?
17:11:19 <coremodule> Okay, sure. Just making sure we had an actual criteria this would fall under.
17:11:43 <adamw> yeah, it'd be that.
17:12:04 <adamw> so...i think i'd suggest we put this in ON_QA and ask if anyone thinks the bug as described is still present
17:12:05 <adamw> if not, close it
17:12:13 <jlanda> +1
17:12:15 <adamw> so that'd be a punt, i guess, in blocker terms
17:12:33 <adamw> or to make things cleaner we could just close it :P and re-open if there are still issues.
17:13:16 <lruzicka2> Ok, let's try closing it and see.
17:13:36 <lruzicka2> before, I suggest accepting it as a blocker, thoughh
17:14:17 <jlanda> It's a clear blocker, but well, doesn't matter if we are going to close it :D
17:14:18 <adamw> i don't think i'd want to accept it as a blocker *right now*, on the basis of what we know
17:14:28 <adamw> let's say we accept it ,close it, it gets re-opened
17:14:32 <lruzicka2> my reasoning: This behaviour is clearly a blocking one, but since the problem is gone, we can close it.
17:14:44 <adamw> i'd want to look at exactly why it got re-opened and whether whatever issue the person re-opening it has actually constitutes a blocker anyway
17:15:01 <adamw> i wouldn't just assume that the blocker status we'd awarded the bug was 'valid'...would you?
17:15:25 <jlanda> we should revisit it yeah
17:15:29 <bcotton> i agree with punting and re-evaluating if needed
17:16:06 <adamw> okay now i'm confused
17:16:27 <adamw> so my current proposal is just to close it, which means we don't have to make any blocker decision
17:16:31 <adamw> is everyone ok with that?
17:16:31 <lruzicka2> adamw, so if a system does not boot because of erroneous service .. that is not a clear blocking behaviour?
17:16:33 <jlanda> I'm fine with just closing, we can propose it again if it's reopened
17:16:52 <bcotton> adamw: yes
17:16:56 <coremodule> +1 closing and seeing if it's reopened
17:17:01 <coremodule> seems cleaner that way
17:17:04 <adamw> lruzicka: depends how the system got in that state. say it turns out that if you got the bad update, you need to fix it manually...that's not a blocker.
17:17:28 <jlanda> I understand that adamw would prefer to reanalyze all again in case it's reopenee so he is in favour of just closing to reexamine the situatiom in the future
17:17:32 <jlanda> If needed
17:17:42 <jlanda> And not making any erroneous asumptions
17:17:47 <adamw> so long as anyone who upgrades from 29 to 30 on release day (or whatever) doesn't get the bug
17:18:21 <lruzicka2> I got the bug once, unfortunately was involved with different activity, so I only reinstalled the F30 machine
17:18:29 <lruzicka2> this happend on wednesday last week
17:19:41 <lruzicka2> I am not aware of tampering with the F29, I mainly used it for running the dogtail tests
17:19:46 <adamw> hmm, that
17:19:50 <adamw> that's interesting...
17:19:58 <adamw> still, i'd wanna figure out what happened exactly
17:20:22 <adamw> if we just have a bug report which says 'something like this happened but that's all i know', it's kinda hard to fix. or be sure you've fixed it.
17:20:40 <lruzicka2> unfortunately I cannot provide any data .., I know.
17:21:50 <lruzicka2> I did not want to lose my focus for something else. It is wierd that there were so little occurences.
17:21:50 <adamw> ok, let's just close it and move on. nothing is irreversible after all. :)
17:22:00 <lruzicka2> all right
17:22:51 <adamw> #agreed it seems pretty clear that this specific bug - dbus always winding up disabled on update to f30 package set - is now fixed. there may be some related / similar problems still, but we will close this bug and consider any other issues on their own merits if proposed
17:25:24 <adamw> #topic (1656509) F29 to Rawhide (F30) upgrades fail, seems to be modularity-related
17:25:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1656509
17:25:24 <adamw> #info Proposed Blocker, fedora-repos, NEW
17:26:10 <adamw> so we actually got working upgrade tests in the latest rawhide compose
17:26:16 <adamw> f29-f30 as well as f28-f30
17:26:23 <adamw> so it seems like someone did something to fix this, but i'm not sure who or what
17:26:25 <adamw> sgallagh: any ideas?
17:27:32 <Lailah> Hi
17:28:03 <lruzicka2> Lailah, Hi
17:28:18 <Lailah> Sorry, I'm late
17:28:24 <adamw> hi lailah
17:29:01 <Lailah> Hi Iruzicka2 and adamw !
17:29:11 * Lailah waves a hand
17:29:12 <adamw> Lailah: we're just on the second proposed beta blocker now
17:29:20 <Lailah> Oh okay
17:29:59 <Lailah> Which one is?  Sorry, I've been away the whole day
17:30:42 <sgallagh> adamw: Last I looked at that, it was a DNF issue and I didn’t hear anything about a fix landing yet.
17:30:49 <sgallagh> (Also, I’m on vacation)
17:30:54 <adamw> Lailah: it's in #topic
17:31:29 <Lailah> Jeezaz...  what's that....
17:31:57 <Lailah> Sorry, I don't see the topic
17:32:22 <adamw> sgallagh: wait a sec...just let me find my dictionary...'v'...'vacancy'...'vacation'...huh! you learn something new every day
17:32:24 <Lailah> Ah, F29 upgrade fails?
17:32:29 <adamw> Lailah: yeah.
17:32:38 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1656509
17:32:57 <adamw> so, i guess we could just accept this one as it stands, and worry about whether it's been fixed later...
17:32:59 <jlanda> It seems fixed but we are not sure why and how... punt and see how the bugzilla bug goes?
17:33:00 <adamw> my vote would be +1
17:33:02 <Lailah> Oh, nice, thanks. Give me a sec to read
17:33:14 <sgallagh> For the record, it’s a clear +1 blocker from me.
17:33:40 <Lailah> adamw:  you didn't know what vacations look like  xD
17:33:52 <bcotton> +1 blocker
17:34:18 <jlanda> fine
17:34:53 <lruzicka2> +1 blocker
17:34:54 <Lailah> Yes, my vote is +1 to blocker too
17:35:50 <sgallagh> jlanda: Whether it’s fixed doesn’t change whether it’s a blocker. It could be not actually fixed and the tests got it wrong.
17:36:03 <sgallagh> Or it could get reverted, etc.
17:36:53 * sgallagh goes back to day-drinking
17:36:59 <adamw> note the difference to the previous bug is really just time: that one's been sitting for like a month now, so it seems pretty clear it no longer exists in exactly the initial form at least. this one only showed up 'apparently fixed' today.
17:37:00 <adamw> anyhoo
17:37:48 <adamw> proposed #agreed 1656509 - AcceptedBlocker (Beta) - this seems to affect just about all F29 - F30 upgrades so clearly violates "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed."
17:38:01 <lruzicka2> ack
17:38:05 <Lailah> ack
17:38:13 <jlanda> sgallagh: yeah sure, but punting we are in time to block it next time, it was a "need more info" punt vote, I'm fine with blocking now since we the information we have it's a clear blocker
17:38:16 <jlanda> ack
17:38:23 <bcotton> ack
17:40:30 <jlanda> s/we the/with the
17:40:36 <adamw> #agreed 1656509 - AcceptedBlocker (Beta) - this seems to affect just about all F29 - F30 upgrades so clearly violates "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed."
17:40:51 <adamw> #topic (1654841) 32-bit ARM systems upgraded from <F30 to >=F30 will have non-BLS bootloader, but grubby-deprecated will not be installed
17:40:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1654841
17:40:51 <adamw> #info Proposed Blocker, grubby, MODIFIED
17:42:29 <adamw> i built the package with the planned fix for this, so i think we can just go ahead and close it
17:43:04 <adamw> #info the fix for this was already built, we will go ahead and close the bug
17:43:12 <Lailah> Okay
17:43:14 <adamw> #topic (1656257) Today after kernel upgrade stop switching video mode on AMD GPU Vega 56
17:43:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1656257
17:43:14 <adamw> #info Proposed Blocker, kernel, NEW
17:44:52 <adamw> hum, interesting
17:45:54 <Lailah> So they know in AMD that it doesn't work?
17:46:12 <Lailah> Did they say if they plan to fix it at some point?
17:47:13 <adamw> dunno
17:47:16 <adamw> but we don't need to resolve that here
17:47:22 <adamw> per #c8, i'd be +1 blocker
17:47:27 <adamw> er, #c7.
17:48:14 <Lailah> Meh...
17:48:16 <lruzicka2> The question would be if that is a purpose or a flaw on the kernel people's side
17:48:36 <adamw> i don't see that that's the question, honestly
17:48:36 <Lailah> Konversation kicks me to a new channel instead of topic or whatever follows to the #
17:48:58 <adamw> whether it's intentional or not, if enabling encryption breaks 'almost all GPU drivers', that seems like a thing we shouldn't do. :P
17:49:09 <bcotton> yeah. +1
17:49:25 <Lailah> adamw:  agree
17:49:31 <lruzicka2> does it touch almost ALL or almost ALL AMD drivers?
17:49:42 <adamw> well, the kernel option is specific to AMD
17:49:48 <Lailah> It says so.
17:50:02 <Lailah> And people from AMD said it was known issue
17:50:18 <adamw> Lailah: lruzicka was asking if the impact is "all graphics hardware" or "all AMD graphics hardware"
17:50:32 <lruzicka2> they might have decided to discontinue all drivers without that support ...
17:50:34 <Lailah> Yeah, I understood
17:50:35 <adamw> the answer atm is "all AMD graphics hardware", I believe, as the kernel option that enables encryption only applies to AMD>
17:50:43 <Lailah> Oh, I replied too short, sorry
17:50:46 <adamw> lruzicka: that doesn't seem like how it reads to me.
17:51:02 <adamw> i agree it's slightly vague, though.
17:51:30 <adamw> vega 56 is not old hardware, though
17:51:33 <adamw> in fact it's very new
17:51:39 <adamw> https://www.eurogamer.net/articles/digitalfoundry-2018-12-7-radeon-rx-vega-56-benchmarks-7001
17:51:42 <Lailah> To me it's clear that the bug is about AMD hardware
17:51:56 <adamw> so i don't think this is a case of this only affecting some older hardware, or something
17:52:43 <Lailah> I think if it affects almost all AMD hardware is a number big enough of users.
17:52:58 <adamw> yeah, so far i'm still +1.
17:52:59 <Lailah> I'm +1 to mark this one as blocker
17:53:07 <adamw> <jcline> adamw, it got turned back off
17:53:19 <lruzicka2> yes, but if the kernel developers did it on purpose, then they will not be willing to change it, right?
17:53:39 <Lailah> Why would anyone do that on purpose?
17:53:42 <lruzicka2> so, seems problem solved
17:53:43 <adamw> lruzicka: this isn't something 'the kernel developers' did
17:53:49 <Lailah> Is it possible to ask them?
17:53:51 <adamw> it's a flag that existed, which pjones changed the state of in the fedora kernel package
17:54:07 <adamw> pjones did it for a specific reason, probably without knowing that it would cause this result
17:55:05 <lruzicka2> this is what I wanted to know ... so is he willing to change it back? seems yes
17:55:35 <lruzicka2> that means, we will not have a blocker here anyway ... it looks like the rest of the bugs we are closing
17:56:01 <jcline> It's been off since December 14th
17:56:18 <lruzicka2> it looks to me that problem is solved
17:56:24 <adamw> yeah, jforbes turned it back off in 92ac1e342116879d2afde4056243afd359ef2924
17:56:39 <adamw> so yeah, let's go ahead and close this one too
17:56:45 <Lailah> Okay, good
17:56:46 <adamw> i like meetings where we close lots of bugs!
17:56:49 <adamw> everyone ok with closing this one?
17:56:53 <lruzicka2> +1
17:56:54 <adamw> thanks for the note, jcline
17:56:55 <Lailah> I'm fine
17:57:08 <jcline> No problem
17:57:57 <adamw> #info the offending config option was turned off again by jforbes in 92ac1e3 , so we will close this bug
17:58:55 <adamw> #topic End of proposed Beta blockers
17:59:10 <adamw> #info we'll move on to proposed Final blockers - no point doing Beta FEs as we're still far from freeze
17:59:26 <adamw> #topic (1658739) dbus-daemon is enabled (but fails to start) after live install
17:59:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1658739
17:59:26 <adamw> #info Proposed Blocker, anaconda, ASSIGNED
17:59:43 <adamw> so, this is pretty simple: on a Workstation install, if you check services, you'll see dbus-daemon enabled but failed
17:59:52 <adamw> it doesn't seem to really break anything much, but it violates the criteria.
18:00:30 <lruzicka2> in that case, +1 blocker
18:01:33 <Lailah> It says that porting to dbus-broker would solve this issue
18:01:55 <adamw> that's the plan, yeah.
18:01:59 <Lailah> Would that take too long?
18:02:02 <bcotton> +1 blocker
18:02:13 <adamw> i wouldn't expect it to. it should be reasonably straightforward.
18:02:32 <Lailah> So maybe we could wait and see if it's solved by the port?
18:02:48 <Lailah> And if it's not solved, then yes, it's a blocker?
18:02:54 <Lailah> I don't know, just an idea
18:03:20 <adamw> that's not how we usually do it, no
18:03:22 <adamw> the issue is a blocker
18:03:27 <Lailah> Okay
18:03:30 <adamw> that means it has to get resolved one way or another
18:03:36 <lruzicka2> it is a blocker, because it violates the criteria, Lailah, when it gets solved, it will be a solved and closed blocker.
18:03:38 <adamw> we leave it to the devs to choose how to resolve it
18:03:57 <Lailah> Ah, okay
18:03:59 <adamw> +1 for me too
18:04:01 <Lailah> Then +1
18:04:35 <adamw> proposed #agreed 1658739 - AcceptedBlocker (Final) - this clearly violates Final criterion "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present"
18:04:57 <bcotton> ack
18:05:13 <lruzicka2> ack
18:05:19 <Lailah> ack
18:05:30 <adamw> #agreed 1658739 - AcceptedBlocker (Final) - this clearly violates Final criterion "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present"
18:05:42 <adamw> #topic (1648268) Drag and Drop from file-roller Does not work on Wayland
18:05:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1648268
18:05:42 <adamw> #info Proposed Blocker, file-roller, NEW
18:06:37 <adamw> i sort of feel like this probably wouldn't pass the 'final blocker' test - sure it's a bug, but you can still basically work with file-roller...
18:06:47 <adamw> it's not like the app reads as utterly broken
18:06:51 <adamw> kinda a subjective call, though
18:07:01 <Lailah> To me it's not a blocker
18:07:21 <Lailah> It's an annoying bug, but...  the programme still works fine.
18:07:24 <lruzicka2> this is exactly the case when "basic functionality test" is not enough
18:08:10 <lruzicka2> I could argue, that drag and drop is how many people use their desktop
18:08:28 <bcotton> but wayland isn't the default on workstation, is it?
18:08:35 <lruzicka2> it is bcotton
18:09:00 <bcotton> oh, well then nevermind :-)
18:09:02 <adamw> yes it is
18:09:18 <adamw> lruzicka: yeah, that's what makes it a bit squishy
18:09:20 <bcotton> i'm weakly in favor of this being a blocker
18:09:40 <lruzicka2> me too, they still will have a lot of time to fix it.
18:09:44 <adamw> there's so many potential ways of using desktop apps it feels very hard to try and draw really clear hard lines of 'this is a blocker' and 'this is not
18:09:54 <adamw> i do *not* like "they have a lot of time to fix it" as an argument
18:09:57 <adamw> if it's a blocker it's a blocker
18:10:01 <bcotton> for the reasons lruzicka2 gave (and the related "would reviewers rip us apart for this?" consideration i have)
18:10:41 <adamw> ok, we have the weak 'point when the bug was discovered' thing in the criteria now, but still, if we just mean 'it's a bug we really hope gets fixed but we don't really mean we'd block the release for it', it should not go on the blocker list
18:10:49 <lruzicka2> adamw, exactly ... therefore I have been talking about specifying the criteria and deciding which apps will just have basic functionality and which will have proper one.
18:11:05 <bcotton> okay, i'll plant a flag and say i'm +1 blocker on this
18:11:16 <lruzicka2> adamw, it seems nobody wants it though, as it creates "more bureaucracy"
18:11:16 <adamw> lruzicka: that ultimately only moves the goalposts, though: what is 'proper' functionality? it still comes down to making subjective calls :/
18:11:52 <adamw> i kinda suspect that, whatever precise word we put in the criteria, people make these votes essentially on their instinctive feeling about how bad the bug is
18:11:58 <adamw> anyhoo
18:12:03 <adamw> let's just count votes and see :)
18:12:11 <lruzicka2> adamw, proper functionality would have to work with all features :)
18:12:18 <lruzicka2> ok, +1 blocker
18:12:22 <adamw> lruzicka: i don't think any app in the distro passes that requirement ;)
18:13:07 <Lailah> I'm -1
18:13:13 <adamw> so that's +2 / -1
18:13:14 <Lailah> It's not a blocker for me
18:13:28 <adamw> i'm still kinda instinctively a -1
18:13:30 <adamw> so we're at +2 / -2
18:13:38 <adamw> when we have a split vote we usually punt, because we're cowards ;)
18:13:46 <Lailah> LOL
18:13:46 <lruzicka2> what about coremodule :
18:13:49 <lruzicka2> ?
18:13:51 <adamw> oh yeah, coremodule?
18:13:57 <bcotton> no pressure, coremodule
18:13:59 <coremodule> hang on...
18:14:01 <coremodule> I'm looking...
18:14:08 <adamw> honestly, whichever way he votes i'm probably gonna suggest we punt
18:14:16 <adamw> we usually look for a fairly strong consensus for blocker votes
18:14:20 <adamw> 3 to 2 isn't that strng
18:14:49 <lruzicka2> if we punt, we will vote again in New Year, right? we have time to postpone decisions
18:14:53 <bcotton> i'm in favor of punting until we have a larger turnout and/or a stronger consensus
18:15:07 <adamw> yeah, basically, the idea is either the bug gets fixed in the mean time, or we vote on it again with more people around and try to get a clearer consensus
18:15:07 <coremodule> I'm +1 to punt
18:15:08 <bcotton> lruzicka2: we have a lot of time. we don't even reach beta freeze until march
18:15:12 <adamw> the voting will continue until morale improves!
18:15:26 <adamw> (insert brexit joke here)
18:15:47 <lruzicka2> adamw, I was thinking about Ireland and the Lisabon treaty
18:15:54 <bcotton> adamw: if it makes you feel any better, i almost said "'blocker means blocker' - t. may" earlier :-)
18:16:01 <Lailah> adamw:  Ouch!
18:16:15 <adamw> =)
18:16:25 <adamw> let me be very clear...
18:16:35 <Lailah> Oh oh....
18:17:46 <adamw> proposed #agreed 1648268 - punt (delay decision) - we don't have a clear consensus on this one (+2 / -2), so if it does not get resolved in the mean time, we'll discuss further and try to reach a clearer consensus at a later meeting
18:17:54 <coremodule> ack
18:17:54 <bcotton> ack
18:17:55 <lruzicka2> ack
18:17:57 <Lailah> ack
18:18:08 <adamw> hey, punting on decisions until the last possible moment? that sure sounds like t. may as well!
18:18:12 <adamw> #agreed 1648268 - punt (delay decision) - we don't have a clear consensus on this one (+2 / -2), so if it does not get resolved in the mean time, we'll discuss further and try to reach a clearer consensus at a later meeting
18:18:25 <adamw> #topic (1659231) No update notifications in current Fedora Rawhide (3.31.2)
18:18:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1659231
18:18:25 <adamw> #info Proposed Blocker, gnome-software, ON_QA
18:18:27 <bcotton> adamw++
18:18:27 <zodbot> bcotton: Karma for adamwill changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:20:03 <lruzicka2> +1 blocker, seems like fix is under way ... but anyway
18:20:10 <adamw> so, as discussed in the bug, the fix for this got built. the test passed in the last rawhide compose
18:20:22 <adamw> so given we have a definite intended fix and it looked like it worked, let's close this one too.
18:20:27 <bcotton> okay, sure :-)
18:20:28 <lruzicka2> then just close?
18:20:41 <adamw> #info this has been fixed over the last few days, confirmed by most recent openQA test results, so we will close it
18:20:49 <lruzicka2> ack
18:20:53 <Lailah> ack
18:22:10 <adamw> #topic End of proposed Final blockers
18:22:15 <adamw> welp, that's everything on the agenda
18:22:17 <adamw> #topic Open floor
18:22:22 <adamw> any other blocker / F30-ish related business?
18:22:29 <bcotton> .
18:23:06 <bcotton> when are we going to hold the next blocker meeting? it would be good to get that out with a little more lead time to help address our indecision
18:23:55 <lruzicka2> if it is in 2019, things will be better ... this is a hurry-up-to-buy-presents time of year
18:24:06 <Lailah> LEL
18:24:38 <bcotton> yeah, the "...in 2019" was strongly in the subtext :-)
18:24:45 <Lailah> To me, this is a "I'm-getting-bored, when-it's-over" time of the year  :-p
18:25:32 <adamw> yeah, in the new year i was planning
18:25:43 <adamw> so not before jan 7
18:25:59 <adamw> if there's more than one or two proposed blockers by then, we'll run one then
18:26:09 <adamw> sound ok?
18:26:09 <Lailah> No blocker review between Christmas & New Year?
18:26:47 <adamw> Lailah: so, red hat basically shuts down between about dec 24 and jan 2 (it's a company policy)
18:26:54 <Lailah> Ah
18:26:56 <adamw> which tends to leak into fedora a bit
18:27:00 <Lailah> Okay
18:27:07 <adamw> of course we *could* run a meeting then
18:27:09 <bcotton> works for me. if you can make the call early on the friday before, i'll add it to my weekly FPgM update on the commblog. not too many people read it, but some people do. it at least gives folks some time to see it as opposed to a weekend or early monday announcement
18:27:43 <Lailah> Yes, I like bcotton idea
18:27:48 <adamw> but usually the rate of change in fedora slows down thanks to all the rh devs being away (so not many new blockers show up), and even if we review and accept blockers, if the person who has to fix it is an rh dev, they won't be around :)
18:27:55 <Lailah> An early call on Friday would be better
18:28:08 <adamw> bcotton: i'll try. i often wind up forgetting and doing it on saturday or sunday though :/
18:28:29 <bcotton> adamw: i'll make a note to check with you
18:28:31 <adamw> if you remember to check, and i didn't send an announcement by friday, just ping me on irc
18:28:32 <adamw> thanks
18:28:47 <lruzicka2> I think that the next meeting should be in 2019, otherwise the voting results wont differ much
18:29:01 <Lailah> Yes, I agree
18:30:41 <adamw> alrighty then, so next meeting is jan 7 if there are sufficient bugs to discuss
18:30:44 <adamw> anything else, folks?
18:33:30 <adamw> well then! thanks for coming, everyone
18:33:34 <adamw> and happy holidays!
18:33:48 <adamw> let's hope everyone finds a fresh blocker bug in their christmas stocking
18:33:51 <adamw> ...actually no, that would be awful.
18:33:53 <lruzicka2> happy holidays to you too
18:34:11 <lruzicka2> heh :D
18:35:49 <Lailah> adamw: LOL
18:35:56 <Lailah> But it might be fun
18:36:06 <adamw> i think i'd prefer chocolates.
18:36:11 <adamw> #endmeeting