Leaderboard

There is a big topic left I want to discuss and that's the continued use of SVN. Up until yesterday I was under the impression that the goal of the migration is to replace the use of SVN for all development of 0ad (while keeping read-only SVN access). I obviously should've read the documentation in detail earlier, but after doing so and after a lot of questions answered by @Itms and @Stan` (thanks again for that) I believe I understand the planned setup and its motivation now. Unfortunately I feel like the migration is one step forward and one step back. Let me explain why: Right now when working on patches and trying out development snapshots I use the git-mirror of 0ad on Github (https://github.com/0ad/0ad). The only time I have to use SVN is when I want to actually commit something. With the planned setup that'd not be the case anymore and I'd need SVN to even compile 0ad, because the contents of the "source-libs"/"windows-libs" SVN repositories are needed for that. I'd also need SVN to test different locals with a development snapshot, as translations aren't planned to be included in the git repository anymore. I believe it's fair to say the new setup is much more complex. Previously it was a single SVN repository, with an 1:1 git mirror, now it's one git-repository and three SVN repositories, which share different subsets of code and/or binaries. The only one of these repositories which contains everything (albeit with more coarse-grained commits) is the "nigthly-build" SVN repository. As that's read-only, every developer will have to interact with git and SVN in future. While one of the big benefits of Gitea is the possibility to use pull requests, that won't be possible for changes to the "source-libs" and "windows-libs" SVN repositories, as Gitea doesn't support SVN. Learning about these constraints pulled me down a bit, but let's see if we can get some ideas for improvement out of that. Going back to square one, what are our expectations for the migration? Mine are: All development for 0ad happens in git afterwards. A comfortable web-frontend is available for browsing git repositories, collecting issues, discussing and merging patches and managing documentation. Build artifacts aren't included in the source code repository anymore. A 1:1 SVN-mirror is available (essentially the equivalent to the git-mirror we had so far). Based on that, here is what I'd suggest: keep the planned 0ad git repository and the use of Gitea commit translations and translation credits into the 0ad git repository again (I don't see a good reason why translations should be handled differently from assets or "programming.json" and having them in git makes everything easier) integrate the contents of the "source-libs" SVN repository into the 0ad git repository again instead of using a "windows-libs" SVN repository, put its contents into a git repository, utilizing Git LFS, and include it in the 0ad git repository as submodule add an additional git repository for build artifacts, utilizing Git LFS, and include it in the 0ad git repository as submodule make an SVN-mirror available with git-as-svn (https://github.com/git-as-svn/git-as-svn) By doing all of the above there would be no SVN repository in use anymore, but everything would still be accessible through SVN. The contents of the 0ad git repository and the SVN mirror would be identical and the mirror would always return the most recent content from the git repository. Changes for all repositories could be handled via pull requests in Gitea. While the git repository would be larger than with the currently planned setup (because of the added translations and source-libs), I believe that's warranted given the history of the project and the size of the code base. Partial checkouts using SVN would still be possible and the necessary storage space on the server might even be lower, as git-as-svn is just a bridge between git and SVN. What do you think about that? What did I miss? Do my ideas even make sense?

Where would something like https://github.com/0ad/lobby-infrastructure/ fit with that?

I'm not the sole decider for this, but what do you expect for the "official" part? As opposed to say, community balancers. There is indeed a lot of writing to be done on 0 A.D. whether it's in the game or in the documentation, but you currently do not need more permissions that you currently have There is also the design document, that has never been updated to reflect the current state of the game that could benefit from a polish. Then there are the side tasks like adding new tips to the game https://code.wildfiregames.com/D4189 @Nescio did a very good job standardizing unit tooltips and whatnot and perfecting the english style guide. There were also some more debatable changes like changing stone to rock and and metal to ore in the editor but overall it brought a layer of consistency which is welcome. Now I must warn you though, this is a thankless job, and it will often happen that stuff gets in and needs to be corrected afterwards.