Meeting started at 2025-08-13 17:03:29 UTC

The Meeting name is 'fedora-server'

Sorry for the delay! It is too hot today.

!hi

Paul Maconi (aggraxis) - he / him / his

As usual, let's wait a moment for everybody to show up.

I'll post the agenda in 2-3 minutes.

!hello

Emmanuel Seyman (eseyman) - he / him / his

!hi

!hello

Jocelyn Gould (korora) - she / her / hers

Jocelyn Gould (korora) - she / her / hers

Welcome everybody. I guess, we can start now. We meet our quorum.

I suppose, we have to skip topic 4 (Improvement ...) I couldn't finish my proposal yet. But let's see.

In Open Floor we should discuss the current status of our documentation.

Any comments, propoals, additions, deletions , .....?????

No, that looks good to me

OK

Regarding the action, nothing new. See

Release 43 was branched yesterday. This means we are now entering the “hot phase” of testing. F43 release testing is now a regular topic at our meetings.

Regarding changes in release blocking criteria.

https://discussion.fedoraproject.org/t/proposal-drop-optical-media-boot-release-criterion/160524/2

One proposal is now set in action:

https://discussion.fedoraproject.org/t/proposal-limit-release-blocking-status-of-bios-systems-to-just-certain-scenarios/160757/14

Does someone know about the RAID issue?

No I haven't done any RAID testing

I don't have a system to test RAID on

Same

Well, lets see what happens with RAID 1 blocking status.

Has someone else something to add here??

Did we get a new compose after the branch?

Not yet, as fas as I know

We do not have a F43 compose, no

Ok. It's probably coming soon, then.

Usually, we get a new test build 1-2 days later. Depends how many issues produces the build system.

Usually, we get a new build to test 1-2 days later. Depends how many issues produces the build system.

OK, let's go on

Tracking issue: !link https://pagure.io/fedora-server/issue/164

I updated the tracking issue to the latest rawhide built.

As mentioned on email list I found a serious bug in all installation procedures with the build before the last one. I could test the latest one yet.

We have (at least) one issue to resolve. We must be more present in the testing result matrix. I get crazy with that lis.t

I should be able to test this weekend

Is there a link for that list?

I don't know what this weekend looks like for me, but I can probably try to do some testing

Good. I will test the software raid procedures. I seem to be the only one with a test eqjuipment for this.

We need test with a default installation on hardware and on VM. We need testing our VM image. And we need testing the aarch64 SBCs. With the latter i found an issue again, arm-image-installers has issues if you use Server as installation host, again.

Please, can someone take care to add links to the appropriate locates in the test matrix, where we can add our results?

We have to adjust them with each new testing release. But hopefully, we have a bases.

Obviously, no further comments at the moment. Can we agree that everyone will briefly announce their results on the mailing list and enter them under the tracking issue?

yes, that sounds good

Thanks, let's see how it works out. We urgently have to systemize our testing.

Are we going to wait for a post-branch build?

Sounds goo dto me

That build artifact link is pre-branch

Well, at the moment is seems best to wait for the first branch.

We will likely get asked about image size again as well. It's failing the auto test for that.

But we should continue (or probably start) to test rawhide builds every 2-3 weeks in parallel.

Regarding the image size, as long as we don't systematically work on modifications of our install images, we can not do much. In a discussion with Nirik on Flock we want to work on an improvement if this situation.

We postponed that, because there was some rumor about changes in the build system. But at least for the foreceeable future it will stay as is.

Another issue is, to monitor the change proposals for potential issues. Emmanuel Seyman could you have a look into this?

We already kno about the dovecot issue

Yes, I've been meaning to do this but $WORK is driving me crazy

This $WÓRK is really annoying :-) For me too.

Planned for this weekend

OK, let's see how it works out. Next topic.

no Tracking issue yet

I have started digging into our issues

I am going through things that are low hanging fruit like typo corrections, etc. and acting on them/closing them out.

Jocelyn (she/her): your turn :-)

My turn? I'm not sure what I'm bringing other than my writeup on how to setup a pxe boot server. LOL

We have a series of issues that are overcome by events, and I will work on closing those out as well.

Last meeting we said, you will have a look at the tickets and make a proposal, how to proceed / hor to fix.

Hello!

There are a couple that are end user support that look invalid, and on at least one I reached back out for comment but got nothing this week.

Late again

Welcome mowest !

hey mowest :)

My life has been hectic and I haven't gotten there yet.

Welcome mowest

I am also looking at some of the commits we have in the staging branch that might fix some of the issues in main and can cherry pick those if they line up.

Jocelyn (she/her): Yeah, that's life in reality :-)

hello, mowest

Paul Maconi (Aggraxis): I think, most relevant are the PRs. It's really a shame we didn't take care of those for such a long time.

Yep. It's all making progress. You will see it shrink. by next week.

Maybe, we discuss the more difficult or very old tickets on the mailing list? And postpone this topic to next meeting?

We're down to 30 open issues right now.

That's progress !

37 sorry

OK, no that progress :-)

I think I closed 5? I wasn't counting.

We have many that are candidates for summary closure due to events (testing goals for F41, for example)

Paul Maconi (Aggraxis): Paul, can you take care of posting the more complex tickets individually to the mailing list or our Matrix Room?

Yes

Yes, some are really outdated. Some are difficult, e.g. our long running projects, e.g. 88, 86 and many more

OK. let's continue on mailing list and / or Matrix room. Our discussion on Matrix about the documentation was very good. We should make that permanent :-)

Well, let's go on

no Tracking issue yet

see previous discussions, e.g.

Folks, we really have to systematize our testing and document it and make it transparent.

I wanted to write an proposal, but unfortunetly couldn't manage to do it.

For me, the biggest hurdle is that the points we have to pay attention to according to the list are so difficult to find, at least for me. They get lost in all the incredibly numerous standard tests – at least for me.

And we have the plan for a test day.

Unfortunately, no progress there yet.

I'm not sure if all of us are comfortable or familiar with the test case lists, either.

Our idea was, to modify the test mail including direct links, and to initiate a test day or test week.

I agree but it seems like when we have discussed this in the past there is a disconnect between what we know gets tested automatically and what actual meaningful manual tests need to be done before a release. Adam our QA guy has so much domain knowledge and we don't seem to grasp what would make the biggest impact and how to report that to those that can enact change.

Paul Maconi (Aggraxis): same to me, after 5 years of working on Fedora Server

I know at least Jocelyn (she/her) and I haven't performed formal release testing yet. Most of my testing in the in-between time has been update-specific testing for various SIGs

And that's just a matter of install, reboot, try, karma.

At least I haven't grasped it.

mowest: Yes, that's the issue !!

I guess we can take a look at QA's documentation.

We need more clarity and explicit procedures.

I just want to make sure we're meeting QA's expectations.

Paul Maconi (Aggraxis): agreed!

We agreed so far, we need to do the bare metal installations, because they can not be automated.

I can chat with adamw if he has time.

And we need to check, if the documentation still applies

Paul Maconi (Aggraxis): If you read the mailing list discussion linked above, you should get an impression, what we discussed and where the problems are-

In the past I feel like our WG has been talking past the QA group, because there are times when we suggest something to test and message might come back, that is already auto tested or QA doesn't seem a reason for that test. I'm not sure how to fill in the gap so our work can be more helpful.

In the past I feel like our WG has been talking past the QA group, because there are times when we suggest something to test and message might come back, that is already auto tested or QA doesn't see a reason for that test. I'm not sure how to fill in the gap so our work can be more helpful.

mowest: I think, there are a lot of gaps. The automated tests just cover the basics. But not to get something really into action.

These additional tasks are in our installation documentation. Therefor it is important to check them.

I have run through our post install docs in the past to verify that those still give us the intended result which they did, but I don't believe I reported that to QA in a meaningful way but maybe I didn't need too, because my report to our WG is all that is needed.

We have identified the problem, I would need to think to come up with a clear solution.

Yes, we should continue to seek a solution. And maybe, I can manage o write up a summary of our discussion so far. We had a lot of them, bu it Is hard to remember after such a long time..

OK, let's go on and continue this on mailing list and in Matrix room.

Our time is up, but we may spent a short time anyway.

Nothing big for open floor, but I got docker running on my test server. I know podman and systemd are the Fedora way but in the homelab world there is so much that is just docker compose file and go.

As Emmanuel Seyman recently noted, there is now a significant gap between our documentation staging and published versions. The question is how we can resolve this.

That sounds super important to sync those.

mowest: We are still missing a podman installation documentation :-)

I use podman on my server, but I am still trying to wrap my head around quadlets

My son and I are still struggling to get rootless containers to work right with different projects running on podman quadlets.

Yeah, all that is really worth of a documentation!

Jocelyn (she/her): My son understands quadlets way more than I do, but he struggles to dumb it down for dad. He wrote a python script to turn docker compose files into podman quadlets.

So he had the right systemd files

mowest: and Jocelyn (she/her) Can't we turn this into a joint documentation project for servers?

Yes we probably should. I will see what I can get out of him before he leaves for college.

We probably should, yes

Very good !!

Regarding our web server documentation: Unfortunately, I have not received a reply to my email to the Apache team. I think we have to give up on getting anything from them.

Maybe I'll make one last attempt and write a bug and RFE.

But know we are way over out time setting!

If noone objects I would close now.

3

Sounds good

2

1