<@adamwill:fedora.im>
16:00:22
!startmeeting Quality
<@meetbot:fedora.im>
16:00:24
Meeting started at 2025-12-08 16:00:22 UTC
<@meetbot:fedora.im>
16:00:24
The Meeting name is 'Quality'
<@adamwill:fedora.im>
16:00:27
!topic Roll Call
<@adamwill:fedora.im>
16:00:34
hi folks! who's around for the quality meeting?
<@pg-tips:fedora.im>
16:00:51
!hello
<@zodbot:fedora.im>
16:00:52
None (pg-tips)
<@pg-tips:fedora.im>
16:01:08
(joining particularly to talk about incident management later on)
<@kparal:matrix.org>
16:01:34
!hello
<@zodbot:fedora.im>
16:01:42
Kamil Páral (kparal) - he / him / his
<@derekenz:fedora.im>
16:02:03
!hi
<@zodbot:fedora.im>
16:02:04
Derek Enz (derekenz)
<@psklenar:fedora.im>
16:02:11
!hello
<@zodbot:fedora.im>
16:02:12
Petr Sklenar (psklenar)
<@lruzicka:fedora.im>
16:02:16
!heyhi
<@adamwill:fedora.im>
16:02:23
hi hi everyone
<@adamwill:fedora.im>
16:02:31
lukas, stop inventing your own macros. :D
<@jgroman:fedora.im>
16:02:40
!hi
<@zodbot:fedora.im>
16:02:42
Jaroslav Groman (jgroman)
<@lruzicka:fedora.im>
16:02:46
It was a micro :D
<@jv025:fedora.im>
16:03:18
hey! visiting casually :), may go AFK arbitrarily
<@adamwill:fedora.im>
16:03:39
hi jack and pg, thanks for coming along
<@adamwill:fedora.im>
16:03:48
we've got a lot of topics so let's get rolling
<@adamwill:fedora.im>
16:03:58
!topic Previous meeting follow-up
<@adamwill:fedora.im>
16:05:00
!info "adamw to file an issue to draft a note to the mesa maintainers about this situation, we can follow up on wording and how/where exactly to send it in the ticket" - this was about the mesa update, it got sort of overtaken by events; both involved maintainers were active in the discourse threads so we decided there was no point to the ticket any more. see https://pagure.io/fedora-qa/issue/846#comment-994589
<@adamwill:fedora.im>
16:05:05
any other followup?
<@kparal:matrix.org>
16:06:27
the mesa rpm has a CI pull request from Petr
<@psklenar:fedora.im>
16:06:34
I created PR to enable Fedora CI for mesa: https://src.fedoraproject.org/rpms/mesa/pull-request/98
<@adamwill:fedora.im>
16:07:06
yes, thanks for that
<@adamwill:fedora.im>
16:07:12
and I did a test for openQA
<@adamwill:fedora.im>
16:07:54
!info we have written tests for the mesa layer issue at openQA level - https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/465 - and mesa package level - https://src.fedoraproject.org/rpms/mesa/pull-request/98
<@adamwill:fedora.im>
16:08:44
!topic Fedora 44 status
<@adamwill:fedora.im>
16:08:48
erf, brb, sorry, just a sec
<@lruzicka:fedora.im>
16:09:04
There is the Basic Networking test case proposal.
<@kparal:matrix.org>
16:09:22
Petr Sklenar: I see that Adam also uses `vkcube --c num` approach
<@kparal:matrix.org>
16:09:42
I added such a comment to the mesa PR, just FYI
<@kparal:matrix.org>
16:10:08
oh, the topic changed already, don't mind me 🙂
<@psklenar:fedora.im>
16:10:35
yes, its the same, just headless in fmf , --c kill that; I reply to you comments in PR with bugy mesa version
<@kparal:matrix.org>
16:10:57
Lukas, I didn't want to review it because it was too long 😄 But I motivated myself with sweets and I did.
<@adamwill:fedora.im>
16:11:57
!info Lukáš Růžička proposed a basic networking test case, please take a look at https://fedoraproject.org/wiki/QA:Testcase_Basic_networking
<@kparal:matrix.org>
16:11:59
I think it's good, but it should be work for robots, ideally
<@lruzicka:fedora.im>
16:12:06
It is too long because I wanted that everybody could set up basic networking if they did not have any locations to test with.
<@lruzicka:fedora.im>
16:13:00
If for example, someone has an SSH access somewhere, they could just test that, but if they don't they could use two virtual machines to do it - and, as you say, I will convert it to an openQA test
<@adamwill:fedora.im>
16:13:29
yeah, my gut reaction was 'too long' but as i looked at it i do kinda like the coverage
<@kparal:matrix.org>
16:13:33
btw, is static network config a requirement from our criteria? Or it is included just because it makes testing simpler?
<@kparal:matrix.org>
16:13:47
Well, not simpler, but less variable
<@lruzicka:fedora.im>
16:14:12
the criteria mentioned DHCP and static, I think
<@lruzicka:fedora.im>
16:15:09
openQA sets static connection, if I recall that correctly.
<@kparal:matrix.org>
16:15:38
on a related note, I don't think we need to have 1:1 mapping between openqa tests and wiki tests. I'd like to see much more openqa tests than we have wiki tests, and we don't necessarily need to have it on wiki just to be able to fill a "pass" result there. I think this is a prime example where I'd expect the openqa test to be much more complex and long (too long for humans), and the wiki test should be a different one, tailored towards humans
<@adamwill:fedora.im>
16:16:04
we already have more openQA tests than wiki tests
<@adamwill:fedora.im>
16:16:12
but we *do* want a 1:1 mapping between criteria and wiki
<@adamwill:fedora.im>
16:16:17
or at least, we want all the criteria covered by wiki tests
<@kparal:matrix.org>
16:17:24
I'm not sure if it makes sense to have a testcase that will only serve as a basis for implementing it in openqa (and of course diverge in future), which is not intended for manual testing
<@kparal:matrix.org>
16:18:11
sure, it can be there, but in the actual release matrix, I'd like to see the human one instead
<@adamwill:fedora.im>
16:18:40
i think this does work as a human test case as well
<@adamwill:fedora.im>
16:18:50
although as I said it's not how I *envisaged* writing a test case
<@kparal:matrix.org>
16:19:23
I already covered that in test list, so I don't want to repeat it here, but I think it will need more work and more length in order to make it suitable for humans
<@adamwill:fedora.im>
16:19:24
I was thinking in theory we could say "...or just ignore all this, rely on your default network config, and try pinging 8.8.8.8" or something, but didn't see an elegant way to add it
<@adamwill:fedora.im>
16:19:46
anyway, yeah, we can follow up further on list
<@kparal:matrix.org>
16:21:09
I can do the testcase (adjust the bits that need adjusting) just because I already know all the necessary networking basics. But for general (test) audience, I think it will need even more explanations.
<@kparal:matrix.org>
16:21:57
I think it would be better if humans just tested their default network without static networking etc
<@kparal:matrix.org>
16:22:57
it brings more value if it actually tests their NIC/Wifi card, than a virtual network (those failures will be caught by automation anyway)
<@kparal:matrix.org>
16:23:05
it brings more value if they actually test their NIC/Wifi card, than a virtual network (those failures will be caught by automation anyway)
<@lruzicka:fedora.im>
16:23:29
The problem is that I cannot test IPv6 on my network connection. I mean, I have some IPv6 assigned, but I wasn't able to ping anything on IPv6 and then I read about the fact that it depends on the provider. Therefore, I decided to make it that way.
<@kparal:matrix.org>
16:24:26
yeah, that's again a good case for automating ipv6 basics, and maybe not even mandate it for humans. Just let them use the defaults that Fedora boots with.
<@lruzicka:fedora.im>
16:24:53
Also, the connectivity will somehow always depend on what the provider settings will be, firewalls, etc. This is a complex problem :D
<@kparal:matrix.org>
16:25:18
sure, but the primary goal is to test "does your network boot after installing Fedora"?
<@lruzicka:fedora.im>
16:25:28
But ok, I can simplify it for usual scenarios.
<@kparal:matrix.org>
16:25:29
let's continue on the list
<@kparal:matrix.org>
16:25:48
Adam clearly wants to catch his morning beer before it's sold out
<@lruzicka:fedora.im>
16:25:59
no need, it is clear. Let's continue there when I have fixed it.
<@lruzicka:fedora.im>
16:26:10
Sure, I am in a hurry, too.
<@adamwill:fedora.im>
16:26:19
!topic Incident report process proposal - https://discussion.fedoraproject.org/t/174907
<@kashyapc:fedora.im>
16:26:33
I normally heard "morning beer" as "liquid bread" from another Czech colleague :D
<@adamwill:fedora.im>
16:26:42
so hi to P G and Jack Vance , thanks for coming along
<@kashyapc:fedora.im>
16:26:45
I heard of "morning beer" as "liquid bread" from another Czech colleague :D
<@lruzicka:fedora.im>
16:27:13
liquid bread is the common name for beer
<@kparal:matrix.org>
16:27:19
and what's **your** breakfast, Kashyap?? 🤣
<@adamwill:fedora.im>
16:27:25
P G i'm more of a Yorkshire Tea man myself, though
<@kashyapc:fedora.im>
16:27:44
Simple: I normally don't. So that it keeps me in my "resting grumpy" face
<@adamwill:fedora.im>
16:28:27
the incident report idea seems like a nice one to me, but it doesn't seem like it really needs its own SIG, we could just make it part of this group
<@adamwill:fedora.im>
16:28:32
what does everyone else think?
<@kparal:matrix.org>
16:28:46
yes. Welcome and be assimilated!
<@pg-tips:fedora.im>
16:29:24
I mean, it would be a SIG of 1 person based on responses to the thread so... yes, being part of QA makes sense 😀
<@pg-tips:fedora.im>
16:29:58
but seriously, yes it makes a lot of sense - when I started out I just didn't want to "volunteer" an existing group for the work
<@jv025:fedora.im>
16:30:03
probably yes, I like @catanzaro propositions the discussion
<@kparal:matrix.org>
16:30:12
I for one welcome the push to make karma a little bit more strict. Even though it wouldn't help in the mesa case. But in others it might.
<@adamwill:fedora.im>
16:30:14
we would rather volunteer you to do the work so we get the credit :P
<@adamwill:fedora.im>
16:30:29
but srsly, yeah, i think it makes sense
<@adamwill:fedora.im>
16:30:47
so, i guess we should figure out next steps
<@kparal:matrix.org>
16:31:29
I would also want a better process regarding negative karma, e.g. having them posted to our #quality:fedoraproject.org channel, that would be great
<@jv025:fedora.im>
16:31:37
2. What is an easy way for a user to figure out which of their workflows to test looking at "dnf check-update --enablerepo=updates-testing" output?
<@jv025:fedora.im>
16:31:37
With this whole Mesa story I see two questions with no answers yet:
<@jv025:fedora.im>
16:31:37
<@jv025:fedora.im>
16:31:37
1. What is a proper process to ask end-users to test not-yet-upstream changes without also asking them to dualboot rawhide and deal with more variables?
<@kparal:matrix.org>
16:31:53
which of course needs having people to pay attention to it, that's the second part
<@kashyapc:fedora.im>
16:32:15
I didn't stay on top of this stuff, how is it being made more strict? Can I read about it somewhere?
<@kparal:matrix.org>
16:32:55
Jack, you seem to be stuck on the "non-upstream" thing. That's a non-issue in my eyes, it's not important. Backports, patches etc happen all the time, and sometimes they diverge because of reasons. There's no reason to distinguish it, though.
<@kashyapc:fedora.im>
16:32:59
(But I only agree, I've seen too many "bare +1" karma with no informative comment on _what_ they tested, etc.)
<@pg-tips:fedora.im>
16:33:36
I feel like somehow a - karma should be weighted higher than +
<@kparal:matrix.org>
16:33:44
Adam proposed higher default karma bars, and something else as well, I'm sure he can find links
<@pg-tips:fedora.im>
16:33:46
certainly if +1 is "wffm, no evident issues in a quick smoke test"
<@kparal:matrix.org>
16:34:06
-1 karma is already super strict, it disables autopush completely
<@jv025:fedora.im>
16:34:07
Kamil Páral: why not important? Exactly, it happens all time. Why not have a proper process for that?
<@adamwill:fedora.im>
16:34:13
in some ways it is. there's a lot of rules, even the novel i wrote in the thread is a simplification
<@kashyapc:fedora.im>
16:34:40
(It's in the Mesa discuss thread, I guess. I'll find it.)
<@adamwill:fedora.im>
16:34:40
for instance, getting a single negative karma disables autopush entirely. the maintainer can turn it back on, but that's already a difference
<@psklenar:fedora.im>
16:34:42
We can have some list of components with karma '-1'; some overview for "last few days"
<@adamwill:fedora.im>
16:35:20
also, by default, getting -3 karma unpushes the update, which is sort of 'parallel' to the default +3 autopush but also a bit 'stricter' in a way
<@jv025:fedora.im>
16:36:22
The AI summary of previous meeting has what I believe to be a very spot-on description “unfortunate string of human mistakes"
<@adamwill:fedora.im>
16:36:42
i think broadly our approach has been that updates-testing/bodhi are there to test whether updates work...regardless the source of the changes in the update, the key question is, 'does this thing break stuff'
<@kparal:matrix.org>
16:36:44
Jack Vance: because there's no meaningful difference. We need updates testing before they are pushed stable. It doesn't matter whether that line is already pushed in some git or not. Different upstreams have different standards, there's no "quality certificate" by having it in the upstream repo. And even when it is, it might be also broken downstream. Also, non-upstream work is a tiny sliver of what we release. It doesn't make sense to have a separate process for it.
<@jv025:fedora.im>
16:36:53
Karma tweaking is good, but 1-click-to-trouble is not good
<@jv025:fedora.im>
16:38:04
Kamil Páral: https://docs.mesa3d.org/ci/index.html as an example
<@kashyapc:fedora.im>
16:38:33
Jack Vance: "What is a proper process to ask end-users to test not-yet-upstream changes" - I haven't been paying deep attention to the whole Mesa thread, but as a broad remark, I'm not sure why is a "process" is required here. A user might have 100 reasons why they want to test with not-yet-upstream changes, why tell them what to test and what not?
<@kparal:matrix.org>
16:39:02
Forget about mesa, we're talking about the whole Fedora, 20k packages or so (probably binary, doesn't matter, simply a lot)
<@jv025:fedora.im>
16:39:24
kashyapc: because as explained by adamw "updates-testing" is not for throwaway builds ;)
<@jv025:fedora.im>
16:40:31
Kamil Páral: yes, and sometimes developers have to apply untested patch without having whole range of hardware to test
<@adamwill:fedora.im>
16:40:41
i proposed https://github.com/fedora-infra/bodhi/issues/6019 and https://github.com/fedora-infra/bodhi/issues/6020
<@jv025:fedora.im>
16:41:16
this Mesa issue is great because it touches a lot of different aspects of what may be required to do
<@pg-tips:fedora.im>
16:41:40
I know what you mean but I also think we should avoid overindexing on the specifics
<@pg-tips:fedora.im>
16:41:53
I would like to get to more general improvements in incident management
<@kashyapc:fedora.im>
16:41:59
Yes, this happens in RISC-V world all the time, FWIW
<@pg-tips:fedora.im>
16:42:03
and this was quite an atypical case
<@kparal:matrix.org>
16:42:12
Any patch is untested, it doesn't matter whether it's upstream or not. If the rest of the environment is different, every patch is untested.
<@kashyapc:fedora.im>
16:42:23
Usually, it's based on trust and community reputation
<@adamwill:fedora.im>
16:43:18
yes, let's try and focus on a path forward for the incident report process :)
<@jv025:fedora.im>
16:43:26
Kamil Páral: There was an article about Valve developer being top 1 Mesa contributor in 2024. Is not testing Steam with Mesa patches reasonable?
<@kparal:matrix.org>
16:43:27
Don't get hung up a clear mistake of a maintainer and blame the process instead
<@adamwill:fedora.im>
16:43:40
i suggested in the forum that we could more or less do the whole process through the forum, as we do for common issues
<@adamwill:fedora.im>
16:43:43
what did people think of that?
<@jv025:fedora.im>
16:43:58
adamw: yes, no SIG needed
<@pg-tips:fedora.im>
16:44:17
I don't hate it, but a couple of things to think about
<@pg-tips:fedora.im>
16:44:39
1) Maintainers are probably more present on Matrix than Discourse - should we also be spinning up a Matrix room per incident to get maintainers engaged?
<@adamwill:fedora.im>
16:44:40
there is some automation/tooling for the common issues process, using issuebot: https://forge.fedoraproject.org/quality/issuebot
<@pg-tips:fedora.im>
16:44:57
2. It might be useful to produce some kind of metrics (monthly, per-release) etc
<@adamwill:fedora.im>
16:44:58
i have a big aversion to a room per <anything> because everyone is in too many rooms already...
<@jv025:fedora.im>
16:45:01
Kamil Páral: yes, I am blaming the process :) this is why I have asked these 2 questions
<@kparal:matrix.org>
16:45:02
if you mean reporting issues, then there's a lot of overlap with common issue. The difference is that with common issues we try to keep some quality bar, which takes time. Also, more people reviewing it and documenting the workarounds etc would be great.
<@kparal:matrix.org>
16:45:41
also common issues are there for a long time, and in this case, the issues will likely be short-lived
<@adamwill:fedora.im>
16:45:54
P G practically speaking i'd say it kinda varies with maintainers, and we'll just have to find them wherever they are
<@kparal:matrix.org>
16:45:55
so we need something faster, leaner, without so many processes
<@adamwill:fedora.im>
16:46:00
if they're active on discourse, great, just tag them in
<@adamwill:fedora.im>
16:46:20
if they're not, find where they *are* active and contact them that way, and offer to proxy things back to the forum if they won't use it themselves
<@pg-tips:fedora.im>
16:46:57
although some amount of process may speed us up rather than slow us down
<@adamwill:fedora.im>
16:46:58
sometimes that's matrix, not always. the freeipa developers are LARPing https://xkcd.com/1782/ for e.g.
<@pg-tips:fedora.im>
16:47:08
enough process that we feel "ok, something's broken, we know the drill for this"
<@pg-tips:fedora.im>
16:47:47
rather than having to stumble through it ad hoc
<@adamwill:fedora.im>
16:48:09
metrics are always fun but they can also be a bit of a landmine. for e.g. if we get better at doing incident reports over time it might look like fedora is getting 'worse' when it isn't, like can happen with CVE reports - projects that are more conscientious about doing CVEs look "less secure
<@adamwill:fedora.im>
16:48:15
metrics are always fun but they can also be a bit of a landmine. for e.g. if we get better at doing incident reports over time it might look like fedora is getting 'worse' when it isn't, like can happen with CVE reports - projects that are more conscientious about doing CVEs look "less secure"
<@pg-tips:fedora.im>
16:48:16
but you all know the culture better than me, so I'm trying to ask questions rather than prescribe!
<@adamwill:fedora.im>
16:48:18
so we'd have to think of a way to avoid that
<@pg-tips:fedora.im>
16:48:35
agreed
<@adamwill:fedora.im>
16:49:26
ok, we still have some other topics to get through and details to figure out...let's see. should we create a fedora-qa ticket for now to come up with a light initial process?
<@kparal:matrix.org>
16:50:08
maybe just having a special tag in #ask in Discussion could work, tagging such an issue would make it quickly appear in a list, and it could be slowly turned into a common issue if longer-lived and with a large impact
<@kparal:matrix.org>
16:50:41
but there's still the question of how you make users aware of "this list of tagged issues that can help you out"
<@adamwill:fedora.im>
16:50:52
my only concern with that is it might just get abused for 'i want people to pay attention to my thread' or something
<@adamwill:fedora.im>
16:51:07
so i was thinking of something a bit more like the 'proposed common issues' / 'common issues' setup
<@adamwill:fedora.im>
16:51:09
but just a tag might work
<@kparal:matrix.org>
16:51:37
well, people do it already in bugzilla, yes. But if we have actual moderators, they can drop the tag if needed.
<@pg-tips:fedora.im>
16:51:50
maybe this is manageable if we have a decent definition of what an incident is
<@kparal:matrix.org>
16:51:56
if we want to have privileges, that would require a subcategory (like Common issues), I believe
<@pg-tips:fedora.im>
16:52:05
and so it becomes easy to say "sorry, we feel your pain, but this isn't one"
<@adamwill:fedora.im>
16:52:17
yeah, that's gonna be a fun part
<@adamwill:fedora.im>
16:52:25
ok...i'll file a ticket and we can discuss the details there
<@jv025:fedora.im>
16:52:25
I am still not convinced. This is discussion about "how to put out the fire faster", not "how to prevent fires"
<@jv025:fedora.im>
16:53:10
which is not bad, but not great either
<@adamwill:fedora.im>
16:53:11
Jack Vance I guess it's true we're focusing on the "incident management" part of the proposal, yes
<@kashyapc:fedora.im>
16:53:22
adamw: I'm wading through this thread to see your suggestion: https://discussion.fedoraproject.org/t/proposal-a-sig-to-improve-production-stability-and-incident-management/174907/41. I hope it's the right one
<@adamwill:fedora.im>
16:53:55
as far as improving production stability goes...i'd say that's pretty much what this team is *for*, so we can just work on specific ideas for doing that within our existing processes?
<@jv025:fedora.im>
16:54:02
adamw: ok, W hould probably wait for "incident prevention" then :D
<@adamwill:fedora.im>
16:54:16
sorry if we didn't get deeply into your ideas in this meeting, we can continue it on the list, or the forum, or the matrix channel, or some tickets...:D
<@jv025:fedora.im>
16:54:23
adamw: ok, I should probably wait for "incident prevention" then :D
<@kparal:matrix.org>
16:54:31
the best prevention is automation
<@jv025:fedora.im>
16:54:51
adamw: no problems, but this is just half-measures
<@kparal:matrix.org>
16:54:52
if you can implement some, I assume any maintainer will appreciate that
<@adamwill:fedora.im>
16:55:01
I was meaning https://discussion.fedoraproject.org/t/proposal-a-sig-to-improve-production-stability-and-incident-management/174907/36
<@kashyapc:fedora.im>
16:55:17
Thanks!
<@adamwill:fedora.im>
16:55:55
!action adamw to file a ticket for further progress on the 'incident management' process idea
<@adamwill:fedora.im>
16:56:29
!info we can consider the 'production stability' aspect in more detail in later meetings/threads/discussions/tickets/whatever people want to create
<@adamwill:fedora.im>
16:56:50
!topic Forgejo migration status
<@adamwill:fedora.im>
16:56:55
Kamil Páral two minutes, go :P
<@kparal:matrix.org>
16:57:17
we're currently "blocked" by https://forge.fedoraproject.org/forge/forge/issues/321
<@kparal:matrix.org>
16:57:28
maybe we're not blocked, we'll see when Ryan answers
<@kparal:matrix.org>
16:57:42
currently all migrated attachments are 404
<@adamwill:fedora.im>
16:57:45
!info forgejo migrations are paused due to an issue with attachment migration: https://forge.fedoraproject.org/forge/forge/issues/321
<@kparal:matrix.org>
16:58:03
I don't want to continue at this point, until we know it's safe and the links will be fixed in time
<@kashyapc:fedora.im>
16:58:16
FWIW, that idea makes sense to me. I'm averse to heavy processes. People come to Fedora to get stuff done, not be mired in processes. So as light-weight as possible sounds good to me.
<@kparal:matrix.org>
16:58:40
(done)
<@psklenar:fedora.im>
16:59:37
about the migration, I noticed that there are some links for filling bug to pagure instead of forgejo, like https://testdays.fedoraproject.org/testday/10 > bellow > "Please file issues and PRs"
<@psklenar:fedora.im>
16:59:56
Should I go through all these "apps" ?
<@kparal:matrix.org>
17:00:01
only fedora-easy-karma is currently migrated
<@adamwill:fedora.im>
17:00:01
please report / send PRs for all cases like that as you come across them
<@kparal:matrix.org>
17:00:08
https://forge.fedoraproject.org/quality
<@adamwill:fedora.im>
17:00:11
for migrated repos, of course :D
<@kparal:matrix.org>
17:00:23
for anything else, keep the pagure links for now 🙂
<@adamwill:fedora.im>
17:00:33
!topic Test Day / community event status
<@kparal:matrix.org>
17:00:39
ah, and issuebot
<@adamwill:fedora.im>
17:01:03
!info kernel 6.18 test week is coming up from 2025-12-14 to 2025-12-20: https://testdays.fedoraproject.org/testday/10
<@psklenar:fedora.im>
17:01:22
!info kernel 6.18 test week https://pagure.io/fedora-qa/issue/852
<@kparal:matrix.org>
17:01:40
we might also get a grub test day soon, related to https://bugzilla.redhat.com/show_bug.cgi?id=2263643 . The maintainers already reached out over email.
<@adamwill:fedora.im>
17:01:44
!info FreeIPA modern webUI test days went off last week, thanks to Petr Sklenar for organizing: https://testdays.fedoraproject.org/testday/9
<@adamwill:fedora.im>
17:02:07
!info a grub test day may be in the works, related to https://bugzilla.redhat.com/show_bug.cgi?id=2263643
<@kparal:matrix.org>
17:02:22
the freeipa test day had a lot of success in the upstream repo (lots of reports), which is not completely clear from our testdays web page
<@adamwill:fedora.im>
17:02:54
oh, that's nice to know
<@kparal:matrix.org>
17:03:05
not sure why, but it's good to keep in mind, that some people report a bug upstream but don't provide a result to our result tracker
<@psklenar:fedora.im>
17:03:09
I heard from freeipa team, that they had 80 issues reported in their upstream project for modern webUI
<@adamwill:fedora.im>
17:03:10
!info freeipa test days led to many upstream reports which are not immediately visible from the downstream page (per kparal)
<@adamwill:fedora.im>
17:04:29
!topic Open floor
<@adamwill:fedora.im>
17:04:34
any other notes in the last -4 minutes? :D
<@kparal:matrix.org>
17:04:43
not really
<@adamwill:fedora.im>
17:05:04
are folks going to be around for the next meeting slot on dec 22?
<@kparal:matrix.org>
17:05:19
I'll be on PTO starting from next week
<@psklenar:fedora.im>
17:05:41
I'll be on PTO starting Dec 22
<@lruzicka:fedora.im>
17:05:46
I am not sure yet.
<@adamwill:fedora.im>
17:06:04
i'm here till christmas eve, ho ho ho
<@kparal:matrix.org>
17:07:38
so I would plan the next meeting for Jan 5th, but do whatever you wish of course 🙂
<@adamwill:fedora.im>
17:07:49
ok, thanks a lot folks
<@adamwill:fedora.im>
17:07:57
see you next time, to be decided
<@kparal:matrix.org>
17:08:06
thanks, bye
<@pg-tips:fedora.im>
17:08:07
thanks everyone, have a great day
<@psklenar:fedora.im>
17:08:25
bye
<@derekenz:fedora.im>
17:08:25
Thanks bye
<@jgroman:fedora.im>
17:08:30
bye!
<@lruzicka:fedora.im>
17:08:31
thanks, good bye
<@adamwill:fedora.im>
17:09:45
if we don't meet again till next year, merry gregorian christmas and new year, happy hanukkah, happy winter solstice, and happy festivus! please don't sue my inclusion department i'm doing my best
<@adamwill:fedora.im>
17:10:24
!endmeeting