Why not moving to Git?

[Stan`]

1 hour ago, hyperion said:

They don't share subdomain so splitting sounds like a good idea regardless?

Need to be on the same VM to do the various migrations. E.g. Trac2git. (need to write a custom plugin for it (cause only things that exist are sqlite and mysql and we use postgres)

10 minutes ago, hyperion said:

Appears to run "git clone --bare", which when testing locally on a btrfs file systems uses reflinks, ie. the clone shares physical extents.

Yeah gitea uses bare repos. On the ext4 it doubled the disk space usage. 

 

[hyperion]

29 minutes ago, Stan` said:

Need to be on the same VM to do the various migrations. E.g. Trac2git.

Maybe leaving trac for bugtracking and wiki independent makes more sense, aka having a global bugs.wfg.com and wiki.wfg.com shared for all projects on git.wfg.com? In case of splitting pyrogenesis and 0ad in future this would be a headache otherwise.

[Stan`]

4 hours ago, hyperion said:

Maybe leaving trac for bugtracking and wiki independent makes more sense, aka having a global bugs.wfg.com and wiki.wfg.com shared for all projects on git.wfg.com? In case of splitting pyrogenesis and 0ad in future this would be a headache otherwise.

Yeah but I have to do the sysadmin work for lack of a better alternative. More applications mean more load on the server and more workload for me. The wiki split is a good point though so it will have to be thought about when it happens.

[Ben Phegan]

Having enjoyed the game a lot, I recently thought that I would look to jump in and start helping by picking up some issues and seeing if I could fix them. 0-AD is a fantastic game, and the amount of work that has gone into it is amazing. However, there are a few friction points that may not be obvious to those that have been working with the project for a while.  Personally I cannot wait until decisions around git hosting and development workflow changes (many of which are impacted by work associated with this thread) are implemented.  

Some thoughts about the current process and the suggested changes from someone new to the project:

1. Having read through this thread, I understand the requirement to self host.  Gitea or https://forgejo.org are great alternatives, but there has to be a realisation that to attract and enable new developers the Github model is the "normal" workflow for your target future developers (me included).  Any deviation will become a point of friction.  And one more point to make on this...if GitHub were to disappear or become onerous from licensing point of view, due to its size and ubiquity transferring to another service would most likely be both automated and trivial for the services that are not already interoperable such as git (ie issue tracking, pages, CI etc).  This, from my point of view, makes it a negligible and easily mitigated risk.
2. The current approach (SVN, patch files on issues, trac etc) is such a _massive_ issue to attract and enable new developers.  Many developers have _never_ used svn.  They have spent their entire careers using Git and Github, PRs are normal, branching and forks are "the only way".  I am originally from the rcs/cvs generation and have spent a lot of years as a build engineer, and it was jarring to have to find and download a bunch of patch files attached to Trac issues and apply them in an attempt to even build the code. PRs, a consistent git-based branching mechanism, issues alongside the code (not Trac) and frequent merges/CI builds would make things significantly simpler.
3. git-lfs, from my experience, can solve a bunch of the issues with large files.  It is mainstream, can be self hosted, and  is seriously mature now.  It really can be a significant part of the solution.
4. The build process is problematic.  If you can build it in CI, it should be possible to replicate locally...and ideally CI is a _very_ slim shim around default developer workflow.  Jenkins is a great choice, but it would be awesome if developers could model a build environment on the CI process really easily.  It should be (almost) as simple as checkout and run single file.  Moving this front and centre to development process would again simplify the onboarding process.  I have been trying to build 0-ad on multiple OSs (mainly Mac) for the best part of a week, and still hitting issues that require patches or workarounds.  

Really keen on seeing the project become much more accessible to other developers, and happy to help where I can!

[vpereira]

I still fail to see why not use GitHub? It offers zero maintenance costs, and the likelihood of it disappearing is smaller than with any other free service available. I've been maintaining an open-source project since 2006, and for us, GitHub has been a real peace of mind.

[Stan`]

6 hours ago, vpereira said:

I still fail to see why not use GitHub? It offers zero maintenance costs, and the likelihood of it disappearing is smaller than with any other free service available. I've been maintaining an open-source project since 2006, and for us, GitHub has been a real peace of mind.

I think other than opensource dogmatism about not depending on GAFAMS (here Microsoft) and Gitlab being hosted on Azure as well, I think the main reason is we've been bitten in the past by such services, suddenly adding requirements like repo size and file size (Recently source forge asked us to delete some old releases to save space for them) Phabricator was maintained by Facebook and used by Blender until it wasn't.

That's why Gitea has been chosen, and is in good way with @Itms's work.

Moreover we always provided mirrors for those that prefer to use those services.

The lobby is on GitHub, and it has attracted nobody more than it did when using the old SVN workflow.
The community mod is hosted on Gitlab, @real_tabasco_sauce can probably tell you if they feel it's better or not.

On 27/09/2023 at 1:19 AM, Ben Phegan said:

The build process is problematic.  If you can build it in CI, it should be possible to replicate locally...and ideally CI is a _very_ slim shim around default developer workflow.  Jenkins is a great choice, but it would be awesome if developers could model a build environment on the CI process really easily.  It should be (almost) as simple as checkout and run single file.  Moving this front and centre to development process would again simplify the onboarding process.  I have been trying to build 0-ad on multiple OSs (mainly Mac) for the best part of a week, and still hitting issues that require patches or workarounds.  

Well, it's as simple as that, the dockerfiles are there if you're on linux, and you just have a simple shell script to run.

https://code.wildfiregames.com/P241
The main problem we had was cloning 10GB, so we mount volumes instead to reduce the load on the server.

Installing wxwidgets on Windows https://code.wildfiregames.com/P196

Building on Windows https://code.wildfiregames.com/P195

Regarding macos, it's always been an issue, they break stuff on a monthly basis (New xcode version, boom), and it's still a miracle that the team managed to keep making releases for it.
We always had to keep the CI on the lowest macos we support here it's 10.12, which has caused issues, and I bought a mac to tackle the rest, but now that I'm retired, I don't know who will keep on the patches coming.

EDIT: Phab's down again, but I think I also had a script there for macOS, assuming of course no Xcode update broke it.

EDIT2: Github seems to be moving on with this copilot thingy, and whether or not we want to train it more than we already did (Chat GPT 3 has the entire 0 A.D. codebase inside it) is also a concern.

[vpereira]

7 hours ago, Stan` said:

The lobby is on GitHub, and it has attracted nobody more than it did when using the old SVN

But if i understand correctly, the contributions don't happen via PR on Github (or gitea, gitlab), but instead I have to create manually a patch, and upload it to Phabricator,  no?

[vpereira]

7 hours ago, Stan` said:

EDIT: Phab's down again, but I think I also had a script there for macOS, assuming of course no Xcode update broke it.

Yup Phab was offline today, early in the morning, if you did fix it, thank you <3

[real_tabasco_sauce]

Personally, using svn and Phabricator has grown on me. It is quite easy to put together a patch and it seems like a lightweight and flexible approach. I have had to do large pushes to git repositories like my vanilla-ified version of the nomad civs and in some cases it didn't complete, possibly due to the internet upload speed.

One thing I am still unsure of is how to add .png files to a patch in Phabricator.

Overall, I think everyone could get up to speed if everything moved to git, but it would take a while. "If it isn't broken, don't fix it" is kind of an applicable mantra here. That being said, if someone puts together a well organized and well documented repository with instructions on how to contribute, it would be convincing (at least to me).

Edited November 12, 2023 by real_tabasco_sauce

[Stan`]

18 hours ago, vpereira said:

But if i understand correctly, the contributions don't happen via PR on Github (or gitea, gitlab), but instead I have to create manually a patch, and upload it to Phabricator,  no?

For the lobby and the community mod, no.
It's up to the remaining team members, but IMHO once Gitea is setup (It's in good shape), we should migrate to it directly and slowly ramp up the CI(s)

17 hours ago, real_tabasco_sauce said:

One thing I am still unsure of is how to add .png files to a patch in Phabricator.

Currently it's a bit tricky and even harder to download them.

 

[ShadowOfHassen]

So are the issues going to be moved to Gitea as well? Having multiple accounts for bug reports and code is strange.  I've had some good experience with Gitea, and I really think moving to something simpler would be easier. It might help first time contributors if the workflow is as simple as possible.

[Stan`]

5 hours ago, ShadowOfHassen said:

So are the issues going to be moved to Gitea as well? Having multiple accounts for bug reports and code is strange.  I've had some good experience with Gitea, and I really think moving to something simpler would be easier. It might help first time contributors if the workflow is as simple as possible.

Yep the wiki too. The goal is to reduce as much as possible the number of platforms which is one of the reasons I got stretched thin.

[ShadowOfHassen]

7 hours ago, Stan&#x60; said:

Yep the wiki too. The goal is to reduce as much as possible the number of platforms which is one of the reasons I got stretched thin.

That makes sense. (Sorry that you got over worked)

 

Regarding moving wiki I can help with updating some of the wikis to document the new workflow.