Meeting started at 2025-12-10 18:00:53 UTC

The Meeting name is 'fedora-server '

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

I've added one topic I forgot earlier today.

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

!hi

Jocelyn Gould (korora) - she / her / hers

Hi Jocelyn!, Looks like it is just us two, today.

That

That happens from time to time

Yes, especially around this time before Christmas and at the end of the year.

Everyone is busy quickly finishing up the things that have been left undone.

!Hello

!hi

Steve Daley (mowest)

Hi mowest, glad to see you!

Glad to be here...FINALLY!

I think, we can start now – with nirik lurking as usual.

Anything to add / remove here?

not

Nothing to add

not from me

OK

No breaking news here, the list of actions is on our docs meeting minutes page.

Just 2 announcements:

1. FESCo election will start on Monday and is open until Jan. next year.

2. CFP for Flock 2026 in Prag is open. We should start to tink about what we would like to contribute.

There is a lot of time, so we can do that in January

I know right now that I won't make it to Flock 2026, because I believe it is in June. That month is over booked as it is.

I

I hope to vote this year for FESCo elections.

I lack proper documentation to travel abroad so i won't be making it to Flock either

Yes, it is June again, unfortunately. It's the middle of the semester at university.

And regarding the election, maybe we should put some thoughts into it.

I love the idea of an August Flock, that was the time for Rochester NY Flock, and that worked out great for my schedule.

I've not been through elections, so I have no idea what to expect

Yes, August is a lecture-free period. That makes everything easier for me too.

Regarding elections, there will be a voting page and you have to login with our FAS account. And if I remember correctly, you must be a member or a SIG (you are, Server WG) und have sign some kind of copyright page, that you give all your contributrions under the Free Software Licence (I don't know the details, out of my head)

I think the naming is something like SLA agreement.

Maybe you check your account early. If there is something missing, we can fix it.

It would be helpful, if all members of our WG participate on the election.

OK, let's start with the work

On Matrix we had a short discussion how to deal with projects und with detailed tickets about very specific cases, e.g. planing an working on an Ansicvle role / playbook.

The current trend is: we continue to collect everything in one repo, in tickets, and do not open the Ansible repo (or any of the others) with its own ticket system.

This means that, on the one hand, we have everything in one place, but on the other hand, this one place accommodates very different levels of tickets.

Any comment here?

proposed: Agreed: We keep all tickets (and projects), even very specific detailed tickets for areas of the other repo, together in one repo.

The proposal is:

Of course, we can modify it it shows to be not good

I'm a little confused about the Proposal. All the projects we are working on in Server WG are in one repo with all of the issues filed in that same repo, is this correct?

I like the idea of a single place to keep track of what we have in the fire and who is working on the various items

mowest: we have 4 repos, 3 "special": wg docs, usr docs and ansible and the general tickets repo. And the latter takes all issues, that is the 2 special repo don't have a separate issues store.

mowest: we have 4 repos, 3 "special": wg docs, usr docs and ansible and the general tickets repo. And the latter takes all issues, that is the 3 special repo don't have a separate issues store.

I thought originally, that we would have separate repos for Ansible Roles and then another one for Homelab Spin (if we would decide to do this)... etc. But all of the "todo" tickets are in "general"?

Yes, we have the separate repos, but collect all issues in the one ticket repo. The pro is, we have everything in sight.

Oh, I see the 4 repos, and yes, I see that we have a "todo" "tickets" repo.

The con: We have a lot of very detail issues, so it sums up to lot.

Ok, so if I want to bring up a change that would impact the work in Ansible Roles, I would still put it in "tickets"?

I view the todo repo as more of an internal type repo. It's not designed for others, it's for our t racking of things

mowest: Yes

Ok, so if I want to bring up a change that would impact the work in Ansible-Support, I would still put it in "tickets"?

If, after some time, we decide that certain repositories should have their own ticket system, we can change this for each repository.

I believe I can get on board with this method of organization. At least it is a method of organization. The issue might be what happens if I want to edit an "ansible-support" playbook. I would still make a clone of that repo, edit the playbook, and make a pull request, correct?

Same would be true if I wanted to make an edit of the documentation?

mowest: Yes, you clone and push to the special repo. you just create your tickets in the general repo.

The alternative is to set up a separate ticket system for each repo and then mirror it in the ticket repo. That should work; I've also found the place to configure it. We'd have to try it out to see how it works in practice.

Alright, I will support the proposal.

+1

OK, thanks:

I am +1 on the proposal as well

!agreed: We keep all tickets (and projects), even very specific detailed tickets for areas of the other repo, together in one repo.

Any comment / idea / experiences?

Even with our modified structure and workflow with regard to stg and main, conflicts arise during a merge in stg that can be attributed to differences between main and stg affecting articles other than those being edited. I have updated the Git Cheat Sheet accordingly.

OK, it is quite new. So we need a bit of time to check it.

https://docs.stg.fedoraproject.org/en-US/fedora-server/services/filesharing-nfs-installation/

a) NFS Instalation Docs

Jocelyn (she/her): Is this ready for publishing, or do you want to modify / add something?

I would like the return to topic #3 briefly.

mowest: OK, a step back

I love the idea of eliminating stg, because it feels confusing to me because it feels like we have two different sets of docs that are not ever working towards the same goal. I thought the whole idea of the git workflow was that you would clone, create a branch, and edit your branch until is was better than the original, and then you would merge it when done after it has been reviewed by another team member and it was agreed that it was better.

Main should be published, and edits to main should be branches that we have cloned and created to be "Works in Progress"

mowest: You are right. We used stg to have a visible version of the modified article for discussion. Neither gitlab nor pagure had an easy to use preview build into it.

This has changed now, or is going to change.

Directly in Forgejo we have now a rought preview. It should get improved over time.

I like the idea of branching it, keeps things... cleaner

Is there not a way to get a preview of someone's cloned "branch"? I thought that worked, but it has been a while since I have run the preview on my local machine.

So we may drop the stg and use the preview for discussion.

mowest: yes, this is possible now. see:

https://forge.fedoraproject.org/server/user-documentation/src/branch/stg/modules/ROOT/pages/services/postgresql-setup.adoc

That preview of the adoc file seems acceptable. Doesn't look exactly like the endpoint documentation, but it is close enough I would think.

Yeah, it is ok for discussion.

And it will get improved, to meet the Fedora design. But hat will take some time.

Did someone add an adoc interpreter to our instance of forgeo? Is that how that is working? I guess this is one time when it would be better to have everything in markdown, because doesn't forgeo support markdown out of the box?

asciidoc lets us do all sorts of stuff that markdown doesn't. (tip callouts, etc) I've been slowly trying to change all of my personal markdown stuff to asciidoc

We have now an asciidoc formatter. It uses the standard asciidoc html theme. That was (quite) easy to implement.

I'm highly in favor of simplifying the pipeline for documentation. The current pipeline seems very complex, and I feel that eliminating stg for our docs would be a step in the right direction.

OK, proposed: !agreed: We drop stb branch in favour of the AsciiDoc preview in forge.

++1

+1

OK, proposed: !agreed: We drop stg branch in favour of the AsciiDoc preview in forge.

+1

+1

!agreed: We drop stg branch in favour of the AsciiDoc preview in forge.

hello zodbot !!!!

zodbot hasn't liked any of the decisions we have made today.

Is this the first sign of the uprising?

Looks so. OK, we have to do without.

OK, back to 4

topic 4. Pending reviews of our documentation

Given the last two weeks for me, I will need to review it again. I will advise on that once I get a feel for where it is.

Jocelyn (she/her): OK. postponed

Anyone reviewed the postgresql update?

Probably not.

So let's postpone that, too!

Some Idee here?

Same thing, I've not really had time to start doing the research on the dnsmasq version of this. Plan to start on that this week

Same thing, I've not really had time to start doing the research on the dnsmasq version of this. Plan to start on that this week (as well as transition my current dhcpd instance to dnsmasq)

Jocelyn (she/her): The ticket say, you commit to work on it next year, probably together wir Emmanuel to synchronize the manual installation and the Ansible driven

Jocelyn (she/her): The ticket says, you commit to work on it next year, probably together with Emmanuel to synchronize the manual installation and the Ansible driven

The only thing that I would say about "Working Plan", Homelab spin, if we decide to do it I think we need to pull away from a focus on SBC, because supporting Fedora Server on those seems to be too much for most of the boards that are easy to get. I am in favor of a Homelab spin is we are going to keep the current Fedora Server so squarely focused on the Enterprise, one of the biggest changes I believe we need to adopt is bringing Fedora Server in line with btrfs like the other main editions either in a Homelab spin or if there is support on the main edition.

Yep. It's going to take some research on my end, cause I like to understand the how something works. (or not, it helps to understand why it broke )

Imowest: I would be glad if I could remove the "maybe" at the homelab project.

Yes, I also always learn a lot when I write a docs

Because our survey pointed out that our main audience seems to be homelab I guess I would be okay shifting our main edition to make decision more in line with the homelab crowd.

@Jocelyn Yes, I also always learn a lot when I write a docs

I don't want to confuse users who decide to download Fedora for their homelab, so having a separate spin, might be confusing, but perhaps not if we make it clear on the webpage, and the naming of it.

I don't want to confuse users who decide to download Fedora for their homelab, so having a separate spin, might be confusing, but perhaps not if we make it clear on the webpage, and the naming of it in the download repos.

Yes, we should clearly separate the homelab version!

@œmow

mowest: So I remove the "maybe"

Fedora Server - Homelab Spin?

Something like that, yes,

I will need to figure out how to create a Proof of Concept install iso.

I think the naming of that would be... confising

I think the naming of that would be... confusing

And maybe an image for a powerful, but cheap SBD like the rockchip 85xx series.

mowest: My idea is, to stafrt with an ready to use image. As with the vm oder the SBC image.

Fedora Server Homelab Lab? That doesn't sound right

As a larger project, Spins are variations on DE's, more so that Specific use cases. It seems to me that we use 'Labs' for those. So...

Something to think about this week. Our time is up.

Oh right! time is up.

Let's discuss it further on Matrix.

And I have some initial plan on hackmd.io, wait a moment:

Fedora Server Edition homelab spin-off

https://hackmd.io/9FjTMT67Q_Cut0MgW91aZg

You must login to hackmd.io to get access to it.

Any comment for now?

Otherwise we should close, because our time is up

I will take a look at that, I know I have in the past.

Let's close for now.

I have other commitments to get to today.

I have some stuff I'll toss in the main channel re the homelab spinoff

OK, so I close.