#meeting:fedoraproject.org log

<@t0xic0der:fedora.im>

13:59:56

!startmeeting Git Forge Meeting

<@meetbot:fedora.im>

13:59:59

Meeting started at 2025-04-02 13:59:56 UTC

<@meetbot:fedora.im>

13:59:59

The Meeting name is 'Git Forge Meeting'

<@t0xic0der:fedora.im>

14:00:10

!info this is meeting about the Fedora git forge replacement this meeting template can be found at https://codeberg.org/fedora/gitforge-migration

<@t0xic0der:fedora.im>

14:00:21

!topic roll call

<@t0xic0der:fedora.im>

14:01:18

!hi

<@zodbot:fedora.im>

14:01:19

Akashdeep Dhar (t0xic0der) - he / him / his

<@lenkaseg:fedora.im>

14:01:58

!hi

<@zodbot:fedora.im>

14:02:00

Lenka Segura (lenkaseg)

<@dkirwan:fedora.im>

14:02:01

<@t0xic0der:fedora.im>

14:04:14

I will wait until 5 minutes past the hour, but it looks like this one would be underpopulated

<@t0xic0der:fedora.im>

14:05:09

!topic completion kudos

<@t0xic0der:fedora.im>

14:05:40

!info #12 was closed today

<@t0xic0der:fedora.im>

14:05:43

!link https://codeberg.org/fedora/forgejo-deployment/issues/12

<@t0xic0der:fedora.im>

14:05:55

David Kirwan++ for working on this!

<@zodbot:fedora.im>

14:05:57

t0xic0der has already given cookies to dkirwan during the F41 timeframe

<@t0xic0der:fedora.im>

14:06:19

!info #11 was closed yesterday

<@t0xic0der:fedora.im>

14:06:24

!link https://codeberg.org/fedora/forgejo-deployment/issues/11

<@t0xic0der:fedora.im>

14:06:37

lenkaseg++ for working on this!

<@zodbot:fedora.im>

14:06:39

t0xic0der has already given cookies to lenkaseg during the F41 timeframe

<@Zlopez:matrix.org>

14:07:16

!hi

<@t0xic0der:fedora.im>

14:07:17

For folks looking to participate in our efforts, please find our project board here

<@t0xic0der:fedora.im>

14:07:19

!link https://codeberg.org/fedora/forgejo-deployment/projects/13486

<@zodbot:fedora.im>

14:07:19

Michal Konecny (zlopez)

<@t0xic0der:fedora.im>

14:07:36

And our communications over here #fedora-forgejo:fedoraproject.org

<@t0xic0der:fedora.im>

14:10:08

!topic Discussion about planning meeting timings

<@t0xic0der:fedora.im>

14:11:17

Earlier today, folks gathered at the EMEA friendly time, and it was decided that we would like to have only one planning meeting earlier at 0900UTC to 1000UTC

<@t0xic0der:fedora.im>

14:12:24

Unless anyone objects - This will be the last instance of the planning meeting on this time, and we would move the planning meeting over to the 0900UTC to 1000UTC weekly time as agreed upon before

<@nphilipp:fedora.im>

14:12:57

!hi

<@zodbot:fedora.im>

14:12:59

Nils Philippsen (nphilipp) - he / him / his

<@t0xic0der:fedora.im>

14:15:50

!agreed Moving of planning meeting over to 0900UTC-1000UTC time, once every week instead of having two planning meetings

<@Zlopez:matrix.org>

14:15:52

I was on the morning meeting and the time is better for EMEA folks, so no objection from me

<@lenkaseg:fedora.im>

14:16:08

All god for me as well!

<@lenkaseg:fedora.im>

14:16:14

All good for me as well!

<@t0xic0der:fedora.im>

14:16:33

!topic Discussion about the purpose of the Fedora fork of Forgejo

<@t0xic0der:fedora.im>

14:17:23

In the standup yesterday and in the planning call today, we agreed upon not wanting to maintain a fork of Forgejo and instead limit our changes to minimal patches that can be applied retroactively

<@t0xic0der:fedora.im>

14:18:04

Any contributions that are to be made - They are to be made upstream and we will maintain the Fedora fork of Forgejo only to check the compatibility of our changes that pertain to us alone

<@t0xic0der:fedora.im>

14:18:23

Please feel free to add, folks.

<@lenkaseg:fedora.im>

14:19:02

I would have a question about that. So the development of fedora specific changes will happen in the dev environment of upstream forgejo

<@lenkaseg:fedora.im>

14:19:45

How do we test the changes? It can easily happen that our chnges will not be compatible with the upstream test suite

<@dkirwan:fedora.im>

14:19:52

Will make things much easier.. when we get the RPM built for sure.. will simplify the image build and headaches related to keeping everything synced with upstream development

<@lenkaseg:fedora.im>

14:20:08

so will we be patching the tests as well, or have our CI on our fork?

<@t0xic0der:fedora.im>

14:20:21

Specifically, the `forgejo` branch, yes but as that would be synced too, it makes little sense to open up a pull request at Forgejo's (i.e. upstream's end) as the changes pertain to us alone.

<@Zlopez:matrix.org>

14:20:46

I think the CI on our fork is not bad idea

<@t0xic0der:fedora.im>

14:21:17

Having a CI in our fork sounds good but we'd have to write the tests for the changes that we add.

<@t0xic0der:fedora.im>

14:22:36

It is important to note that we would want to keep our changes (that are Fedora Project specific) as minimal as possible and instead, if there are any global changes - consider contributing to the upstream.

<@t0xic0der:fedora.im>

14:23:17

Any objections or concerns on this? I will wait for a couple more minutes before setting this to AGREED.

<@lenkaseg:fedora.im>

14:25:52

So the rpm will be following the forgejo releases with our patches applied on top (+ patches of the tests, in case the test suite will be part of the spec)

<@t0xic0der:fedora.im>

14:26:15

The source tarball, you mean? Yep.

<@t0xic0der:fedora.im>

14:26:29

!agreed The Fedora Project fork of Forgejo is maintained ONLY to test Fedora Project specific changes and any global changes are to be sent upstream as we will not maintain a Fedora Project fork for global changes

<@t0xic0der:fedora.im>

14:26:37

Moving on

<@t0xic0der:fedora.im>

14:27:10

!topic Discussion about the branching mechanism for the Fedora fork of Forgejo

<@t0xic0der:fedora.im>

14:27:22

lenkaseg: Over to you.

<@t0xic0der:fedora.im>

14:28:12

Related ticket -> #25

<@t0xic0der:fedora.im>

14:28:15

!link https://codeberg.org/fedora/forgejo-deployment/issues/25

<@lenkaseg:fedora.im>

14:29:15

So, after discussions with @jednorozec, the branching schema shold follow the uptream one. Upstream's stable branches will be synced with forgejo actions to fedora's v<x>/forgejo branches

<@lenkaseg:fedora.im>

14:29:15

Ah, ok, thanks!

<@lenkaseg:fedora.im>

14:30:04

Then there's fedora fork's main branch, which would be a sync of the latest upstream stable branch with fedora's changes applied on top

<@lenkaseg:fedora.im>

14:31:28

And then there's forgejo branch, which we are not sure if it's worth keeping

<@lenkaseg:fedora.im>

14:32:17

Could serve for testing our changes on latest upstream's forgejo branch changes? Would it be worthy?

<@t0xic0der:fedora.im>

14:33:41

FWIW - I think we need to ensure that our specific changes play well with the point release based branch (i.e. `vX.X/forgejo`) and the rolling branch (i.e. `forgejo`) if we wanna ensure that the Fedora specific changes do not suddenly break in the future.

<@lenkaseg:fedora.im>

14:33:48

During the sync, if there would be any merge conflicts I guess it could open a PR for manual handling..

<@Zlopez:matrix.org>

14:34:30

Maybe the forgejo branch could be used to test devel changes in advance

<@t0xic0der:fedora.im>

14:34:35

But apart from that - I agree that it is probably not worth maintaining the `rolling` branch for global changes. Folks can fork `forgejo/forgejo` repository instead to their own namespaces and contribute to the upstream for that.

<@dkirwan:fedora.im>

14:35:10

forgejo branch is basically the upstream main branch?

<@t0xic0der:fedora.im>

14:35:19

David Kirwan: Yes

<@dkirwan:fedora.im>

14:35:27

So dont mak any changes t here

<@dkirwan:fedora.im>

14:35:41

just keep upstream forgejo synced to our fork forgejo branch

<@dkirwan:fedora.im>

14:35:49

same with upstream v10 and v11 to our v10 and v11

<@lenkaseg:fedora.im>

14:36:02

only they have it called forgejo

<@lenkaseg:fedora.im>

14:37:33

Alright then!

<@lenkaseg:fedora.im>

14:37:53

So that will be another action

<@t0xic0der:fedora.im>

14:38:37

Question - Do we maintain a `main` branch from one of the point release-based branches like we do or should we simply push our changes to the synced branches (with the same name as the upstream)?

<@dkirwan:fedora.im>

14:38:52

its pretty tricky...

<@dkirwan:fedora.im>

14:39:07

but we need to be able to start with v10 at the moment, and put all our changes based on that..

<@dkirwan:fedora.im>

14:39:17

v11 goes live end of april I think

<@dkirwan:fedora.im>

14:39:33

our main branch is probably fine to continue using it as we currently are..

<@t0xic0der:fedora.im>

14:39:39

I was not aware of the fact that the `main` branch of Fedora fork was actually not tracking `forgejo` of upstream but rather, `v10.0/forgejo` of the upstream that led to some confusions.

<@dkirwan:fedora.im>

14:39:52

but just gotta figure out how best to rebase all our commits on top of v10 cleanly!

<@t0xic0der:fedora.im>

14:40:40

That just makes it a lot more important to ensure that the Fedora Project specific changes are minimal, and global changes are made to the upstream instead.

<@lenkaseg:fedora.im>

14:41:10

For the moment quite easily, it's just the UI changes, let's see in the future! It would not be bad to keep our changes somehow separate in different dirs for example, if that's possible

<@dkirwan:fedora.im>

14:41:13

Will be so difficult to maintain if we dont!!

<@dkirwan:fedora.im>

14:41:52

question, what do you think about keeping our fedora specific changes.. in a completely seperate RPM?

<@t0xic0der:fedora.im>

14:42:09

It makes little to no sense when the upstream has it configured and we can sync changes from there.

<@t0xic0der:fedora.im>

14:42:09

The lockfile gave us some pain - Which made me wonder if at all we'd wanna have Renovate configured for our fork.

<@t0xic0der:fedora.im>

14:42:27

!link https://codeberg.org/fedora/forgejo-deployment/issues/20

<@t0xic0der:fedora.im>

14:43:22

The patches would be applied to the source tarballs that we fetch from the upstream `forgejo/forgejo` during building so the answer is `YES`

<@t0xic0der:fedora.im>

14:43:47

nils: can probably fill in the gaps here with respect to how he wants to pursue the packaging ordeal

<@t0xic0der:fedora.im>

14:43:58

!link https://codeberg.org/fedora/forgejo-deployment/issues/16

<@nphilipp:fedora.im>

14:45:39

David KirwanAkashdeep Dhar (he/him/his) Shipping our custom themes, assets etc. in a separate package is a sound approach I guess, just code customization would have to be patches in the `forgejo` package

<@nphilipp:fedora.im>

14:47:27

That could even ship custom configuration (e.g. `/etc/forge/conf/fedora.conf`) and service file (`/usr/lib/systemd/system/forgejo-fedora.service`). If we want that – we can also put this in Ansible I guess.

<@nphilipp:fedora.im>

14:47:48

(A lot of guessing…)

<@dkirwan:fedora.im>

14:47:57

the config might be best handled further up the chain..

<@dkirwan:fedora.im>

14:48:01

but maybe safe defaults?

<@t0xic0der:fedora.im>

14:48:13

Agreed

<@dkirwan:fedora.im>

14:48:59

upstream currently has a lot of dynamic config generation from config in secrets..

<@dkirwan:fedora.im>

14:49:31

bit of crazy juggling in init containers at launch time

<@dkirwan:fedora.im>

14:50:27

if we really wanted to clean some of that up, again its better dealt with contirbuting upstream ;o

<@nphilipp:fedora.im>

14:51:16

Not sure if we want forgejo generating (i.e. able to write) its config, or what am I missing?

<@t0xic0der:fedora.im>

14:52:13

Specifics specifics - Let us pursue this further in the #fedora-forgejo:fedoraproject.org room, folks as we're down to the last eight minutes of the meeting.

<@nphilipp:fedora.im>

14:52:20

As is, the package takes a config file template and fills in generated secrets the first time the service is started

<@dkirwan:fedora.im>

14:53:07

At launch, some of the config is dyamically created at present .. seems overly complex no idea why its being done this way... but if we rip it out we're straying.. and need to patch..

<@nphilipp:fedora.im>

14:53:48

I didn’t have to patch anything to prevent forgejo from trying to mess with the config (and it can’t, permissions eh)

<@dkirwan:fedora.im>

14:54:14

its probably related to if the containers are killed, moved to different hosts, some of the URIs are dynamically upodated to indicate where the containers are running now etc

<@t0xic0der:fedora.im>

14:55:02

Sounds like a bunch of redneck engineering but would have to delve deeper to make sense of it all...

<@t0xic0der:fedora.im>

14:55:17

!topic Open floor

<@dkirwan:fedora.im>

14:57:01

We have a workshop at flock planned dont we? Hopefully will get to use the time to tackle some strategic issues

<@t0xic0der:fedora.im>

14:58:01

We should have some folks from Forgejo on the ground as well during Flock To Fedora 2025 so that should help iron out the specificities of why something has been done in a certain manner...

<@nphilipp:fedora.im>

14:58:03

Ugh… yeah we don’t want that, but I guess this can be fixed or worked around (config key to say "no touch config", passing in node-specific config where necessary, …)

<@dkirwan:fedora.im>

14:58:36

its just at container start time, once the init containers complete, then forgejo container starts

<@dkirwan:fedora.im>

14:58:43

and at that point then there is no more changes

<@dkirwan:fedora.im>

14:59:26

so yeah guessing its going to be something related to handling changes dynamically to where containers are running for example

<@dkirwan:fedora.im>

14:59:59

or maybe its an intern POC that made it to prod

<@dkirwan:fedora.im>

15:00:04

🤷

<@t0xic0der:fedora.im>

15:00:22

Folks, please feel free to join us at #fedora-forgejo:fedoraproject.org room to participate

<@t0xic0der:fedora.im>

15:00:22

Closing time!

<@t0xic0der:fedora.im>

15:00:32

Please do not say that

<@t0xic0der:fedora.im>

15:00:41

!endmeeting