Meeting started at 2026-07-22 17:00:22 UTC

The Meeting name is 'fedora-server '

!hi

!group members server-wg

Brett: Brett Weir (brettweir) - he / him / his

Members of server-wg: Alexander Bokovoy, Adam Williamson, Paul Maconi, Emmanuel Seyman, jwhimpel, Kevin Fenzi, korora (@korora:fedora.im, @korora1981:matrix.org), mowest, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), Peter Boy, Stephen Gallagher

Welcome to our weekly Server WG meeting.

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

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

!hello

!hi

Emmanuel Seyman: Emmanuel Seyman (eseyman) - he / him / his

~hi

!hi

Jocelyn Gould (UTC-4): Jocelyn Gould (korora) - she / her / hers

!hi

bah... zodbot doesn't like me... it probably knows I am not going to stay for the whole meeting :D

!hello

one last try

Ro: Rowan Puttergill (goroboro) - he / him / his

!hi

John Himpel: John Himpel (jwhimpel)

Welcome everybody! I think we can start now.

it likes you!

Wow, zodbot didn't mess up the ordering!

Anything to add / remove?

lgtm!

https://docs.fedoraproject.org/en-US/server-working-group/wg-minutes-2026/

meetings overview:

Regarding the action, see the list in our

Did I forget something?

Good from my side.

That's already a lot of topics...

OK

Announcements:

I opened 2 tickets and proposed @Brett ([ticket 225 ](https://forge.fedoraproject.org/server/tickets/issues/225)) and @Ro ([ticket 226 ](https://forge.fedoraproject.org/server/tickets/issues/226)) as new members.

The following are entitled to vote:

!group members server-wg

Members of server-wg: Alexander Bokovoy, Adam Williamson, Paul Maconi, Emmanuel Seyman, jwhimpel, Kevin Fenzi, korora (@korora:fedora.im, @korora1981:matrix.org), mowest, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), Peter Boy, Stephen Gallagher

Currently, we have 5 positive votes each, no abstentions, no votes against. So we have already reached the quorum. Nevertheless, further votes are welcome. The voting period ends on July 31 (next Friday).

No further announcements from me.

Has someone else any information of questions?

Appreciate the votes, people!

I'm good

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/203

max 10 mins

Yesterday, a new test release came out. How do we process the update of the tickets?

We are lacking behind here.

Currently, all tickets still reside in the Awaiting position.

How do we want to proceed?

well... one ticket could be in the 'In Progress' column :-D

I suppose we need to update all the ticket titles for the correct build

just wondering if there is a way to do that really quickly...

I guess, besides Ro no one else did any testing?

Yes, I could just update all the links to the new test build. That's not such an issue.

I don't know that I'll be able to do any testing before August

Also, now that there is a new build, would we set that issue back to To Do, and test all over again with the new ISO?

And then we simply eave anything in the Awaiting position?

Leaving everything is 'Awaiting' is fine by me

proposed !agreed For release testing, the links in the tickets are updated and the tickets are left in their current positions. The cycle then starts again from the beginning.

proposed !action pboy will update the links in the tickets for testing

I am going to end up getting pretty professional at testing netinst 🤣

I'm guessing htat as long as there is no regression, newer verisons should be able to stay in the 'tested/works' column and then moved if necessary

Yes, but we need / want to track what we have done and what not.

well the only way you would know if there was a regression would be test again... so it would keep having to move back to Awaiting for each build

the comments in the ticket will help to identify if there is a regression because you should have history for previous tests and when the break happened

I think we need a convention around comments... possibly comments need to indicate the build tested?

I'm out of the loop a bit and I don't want to derail the topic, but what do we have in the way of test automation? Is this exploratory testing we're talking about?

Well, I don't see any objection to the proposals? (last chance to come up ...)

I don't know much about how these things are tested at this point.

It's not a problem, if someone doesn't have time at the moment. It's just a problem, if no one has some time. 😏

the QA team has automated some testing and they publish their results for all releases

there's a lot that doesn't get tested

SBC installs, RAID setups, in-place updates from Fedora N-1 to Fedora N

Well, at the moment, it’s more or less an early warning phase. The critical phase will be later in August.

SBC installs, hardware RAID setups, in-place updates from Fedora N-1 to Fedora N

I need to bail on this meeting. Apologies.

Happy doing manual testing for install stuff, because often that catches stuff automation might miss.

Interested in a lot more info around current test automation and how this all fits with that but maybe we can catch up more in [\#server:fedoraproject.org](https://matrix.to/#/#server:fedoraproject.org) .

Oh yeah, these definitely require device farm. I have some experience with this kind of system-level automation but I'm reluctant to take on too many new projects at once. Would this be higher priority than KIWI stuff?

Nobody raised any concerns about the proposals, so let’s wrap up :

👋Adios folks.

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/227

How far have we come? What are the next steps?

Brett: Have you looked into this yet? What can others do to help, and how?

I don't have anything posted yet, but I've been getting some mileage on KIWI. I'm trying to figure out a sane way to do it on a machine without borking it, leaning towards libvirt. Was also trying to figure out if Image Builder was a viable replacement since the Fedora project seems to be inching towards it.

I need a repository to dump things into if we have one.

I imagine some of this might end up merging with the releng repo but I don't want to submit my experiments as MRs to them lol

Regarding image builder: I could be a valid way to go. But currently Kiwi is the tool, releng uses for images (at least mostly).

My understanding so far is that KIWI is a lot more feature-complete. Yeah, it seems to have the most support for live-install environments and fancy partitioning.

The main reason to move away was to support containerized CI/CD but that doesn't seem viable yet.

Brett: You can use the home server repo for config files, set up documentation, etc.

Ohhhh, this one? https://forge.fedoraproject.org/server/home-server

I forgot that existed. 😅

Yes, that one 😀

Gotcha, okay, I can start dumping notes there. I want to have a minimal KIWI environment running in the next couple of days, time permitting.

Can I have access to commit directly? I'm also happy to do PR (keep forgetting on Forge it's PR not MR)

Did you see the kiwi discussion on Discussion? (see the link in my comment to the above mentioned ticket).

Oh, no, I had not seen that, I'll check it out.

Maybe, you can get some inspiration from them. Or some help?

Sure, I'll check it out!

The last few days have been chaotic but I've been able to sit down more to work on it this week.

As an example of a setup documentation we would like to have, you may have a look at the kiwi predecessor:

https://docs.fedoraproject.org/en-US/fedora-server/tutorials/imagefactory/

ImageFactory is gone now. I have to add a note to that article.

Oh, gotcha. I was going to make the project README capture the setup instructions for home server, but are you interested in having a general discussion of KIWI in the server docs too?

Not a general discussion, but in guide how to setup an envirement and how to do the build.

I mean, in addition to what will be in the README?

But maybe not in user doc, but as part of the repo readme

Yeah, okay, I'll focus on README.

But yeah, tech stack is makefile driving libvirt (virt-install, etc.) with KIWI running inside Fedora guest snapshot, and KIWI setup will sync into the VM on each run. So each build will be a clean environment.

I was worrying about where CI would come in too but I can just focus on running locally for now.

Once you get the procedures for this written up, let me know, my 24 core beast can do some testing

By the way, infra may have some more general documentation. Ask nirik . Then you may make it more specific to home server.

Or als Neal Gompa (Fedora) He is member of our WG and promised to help,

sure thing (neochat is glitching but trying to add emojis lol)

Or ask Neal Gompa (Fedora) He is member of our WG and promised to help,

OK, I think we can wrap up and proceed.

Wrapping up:

Thanks for the notes!

Tracking issue: https://forge.fedoraproject.org/server/tickets/issues/210

Open pull request: https://forge.fedoraproject.org/server/user-documentation/pulls/203

What do we have to do here?

I got a bit lost here.

Oh!

!Hello

I propose that we follow the styling standards setforth by the Docs team

My point was that when indicating file paths, we should use backticks, like `/path/to/file` etc.

Yes, and we some more styling specific for server.

Or command names. It wasn't clear to me whether the Fedora Docs team had a standard for this specifically.

Or when indicating CLI names, like `ls -l blah/`. This is for inline code blocks.

Or when indicating CLI names, like ls -l blah/. This is for inline code.

Brett: As far as I oversee, Docs team doesn't have

Using backticks helps prevent undesired command and path breaking and makes them visually distinct in the text.

Are these additions not part of the docs already, could they just be added to the docs maintained style guide so it is all in one place. The main style guide should if it doesn't have conventions for CLI info.

I'm fine with backticks. But I have to admit, that I didn't understand sgallagh's comment.

Oh, it looks like he was changing the phrasing.

mowest: The docs team is mostly busy with desktop users. And there the CLI is not an important issue.

I think, we need a convention now, because we are focus on the CLI. Later we can propose it for Docs team.

Agree with [Peter Boy (ServerWG, Docs)](https://matrix.to/#/@pboy:fedora.im) , it's hard to make a case for site-wide standardization when we don't have an implementation of it to demo.

I like the idea of using backticks

+1 for backticks on cli, paths, ....

Peter Boy (ServerWG, Docs): Do other projects have separate style guides for their documentation? Like CoreOS or Atomic, I would imagine they have some CLI use that is required, and there are references to CLI tools in the main docs like upgrading through dnf. Seems to make sense to have one docs style guide so we aren't maintain separate docs.

I think we should put this discussion on hold for now. And Brett, perhaps you could make a suggestion on how to proceed in the PR, taking sg’s comment into account?

+1 for backticks

+1 backticks

Yeah, I can review, though it looks like goroboro may have already addressed it.

mowest: I don’t know. But I doubt it. I think Server has the most comprehensive documentation of all the editions.

OK, let's wrap up:

Time is up. So let's jump to:

We have at least one minute. The floor is open to anything!!!!

Last minute party!

Sorry about my limited involvement, Wednesday have become my scheduled meetings or appointments out of the office, so it had been harder to attend here.

mowest: Thanks. I hope you manage to attend. We need you specifically for the home server project. 💯

very much so

I suspect we can end this meeting

Well, I see no additional topic for discussion. So let's close before we’re chased off the farm.