Dunedan

I'd prefer if we don't continue mirroring after the migration. With Gitea we'll have an accessible platform for contributors and I'd argue the disadvantages of mirrors outweigh their benefits.

In case the translations end up in Git, here is a rewrite of check_diff.py which supports Git instead of Subversion: https://code.wildfiregames.com/D5312

The "extractors" module isn't necessary in "0ad/translations". "i18n_helper" on the other hand contains functionality used by scripts in "0ad/0ad" and "0ad/translations". I don't like the idea of duplicating this code, as it makes changes to it much more annoying. That's part of the reservations I have regarding a separate translations repository.

I'm not concerned about the complexity of the migration. That's a one-time task. What you and I want to achieve is the best outcome for contributing to the project and managing its infrastructure afterwards. It's just that we seem to prefer different trade-offs. What do you mean by "bundled modules" and what issue exactly did you encounter? As we haven't been able to convince each other which approach is the better one, it's just two personal opinions. In that case I'd suggest moving forward with whatever approach you prefer, as that's the approach you already put time into (and I'm none of the main contributors to the 0ad client application anyway). However, I was hoping to get feedback on the different approaches from other developers as well. If we need a git-compatible checkDiff.py I'd be happy to implement that. You did great work so far and all the late discussion is on me, because I didn't read the details of the planned setup earlier and raised my concerns back then. As mentioned earlier already, I'm really sorry about that.

As the PO-files are excluded via .gitignore I think it'd be fine. As you might have already noticed, I'm just a friend of keeping processes lean and simple and such that circular dependency caught my eye. Without pulling the translations into the nightly-build, how'd you make such builds available in multiple languages? While I brought up the idea of a separate git-repository for translations, after thinking about it for a few days, I believe having translations in the 0ad git repository would still the better trade-off. A separate git-repository for translations just adds additional complexity for very little benefit. For example where would all the scripts related to translations life? For some it's obvious: The one to pull translations would fit well into the translations repository. But what about other ones (to credit translators, to lint translations and POT-templates, ...). One additional thought I had was which translations to pull from Transifex and include. Right now we do that for all languages we have set up in Transifex, no matter if we ship them or not. The volume and rate of changes to translations would be significantly lower, if instead only translations meant to be shipped would be fetched and included in the repository. The obvious downside is of course that testing translations not being shipped yet becomes harder. Just to note: This only works if the source libs are in a git-repository. What are the cases where binaries are part of source libs though? That should be an exception, shouldn't it? Yes, the usual problem with binaries. Reproducible builds would help with that, but that's another can of worms. This depends entirely on the definition of justification. I'd argue all of these commits are justified, as they update translations. What's the difference regarding justification from your point of view between updating a translation and a graphical asset? If somebody doesn't care about translation update commits, it's easy enough to add a custom git alias to not show them in the git history, if they're made with a distinct user just for updating the translations. Does it though? Is it really better for morale to not have recent commits? In the end that's no objective measure, but personal preference. I believe though that a complex project structure is more harmful to contributions (especially from new contributors) than whether there are recent commits or not. Where to find that? I'm not sure if I have access to that right now. I do care more about an easy and accessible project/repository structure and history than optimizing just for size. IMO having translations and source libs in the 0ad git repository wouldn't hurt anybody, but would notably simplify the whole setup.

In my opinion having contributors to the wiki credited via the wiki history is fine. As the wiki is just another git repository, extracting and showing them in the credits ingame, would be straight-forward as well. I'd worry though, that it might be difficult to exclude spammers from being credited. In the wiki history it's straight forward to see who is a spammer, as changes are associated with a name, but in the game credits there'd only be a name.

I don't mind if access via SVN continues to be possible, as long as contributors don't have to use it. Good point, it doesn't apply to contributing to library upgrades though. So now the nightly-build SVN isn't a compilation of data from different source anymore, but feeds back into its source again (even though those changes aren't meant to be committed there). IMO cleaner approaches for that would be fetching translations directly from Transifex (which doesn't work, because that requires a Transifex API token not every contributor has), managing them in a separate repository and pulling them from there to the 0ad git repository and the nightly-build SVN repository or just storing them in the 0ad git repository. Wouldn't that foster a culture where certain changes (library upgrades) are done without reviewing them, as there won't be a review tool for SVN anymore. Wouldn't it also make it pretty difficult for contributors without SVN write access to contribute to them? It should be no problem to do that later on. I'd obviously prefer having it from the start, but later on would work for me too. Yes, that probably needs some more consideration. I believe the translations are already even larger than 600MiB. Updating them more often shouldn't increase their size much faster though, because while that would result in more commits, the amount of changes would stay more or less the same (only strings changed more than once between our twice-a-week updates would generate additional changes, but that would be true for the nightly-build SVN setup as well). As git only stores changed data chunks, those additional commits shouldn't do much regarding the repository size. With git, commits are cheap. When looking at the trade-off between the additional size the translations cause vs. not having them in the git-repository & the added complexity of the nightly-build repository not being a 1:1 mirror of the git repository, I'd choose keeping them in git. People who pay particular attention to the size the data takes up on their hard drive, could still use SVN. What's the reason for you negative stance for bot commits to the source repository? Right now that sounds a bit arbitrary to me. I do get the reason for not committing the SPIR-V shaders to the 0ad git repository, but what's the connection to the translations here? Right now you're one of the very few people who can actually change something about it. I'd be happy to support with that though. I believe nobody proposed a single large git repository, with large as in "contains everything the current SVN repository includes" and we all agree that removing built artifacts from the 0ad repository is a good idea. Using submodules we could make it appear as it'd be one large repository though, which would remove the need to use SVN during development and would make having a 1:1 SVN mirror easier. To sum up, I still believe a 0ad git repository (+ submodules for git repositories with compiled artifacts) with a 1:1 SVN mirror would, if possible, be a great win to the reduce the complexity that the new setup introduces.

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?

What I miss in Gitea right now (maybe I haven't just found it yet) is an overview of all (official) public repositories. https://gitea.itms.ovh/ just shows an empty way (aside from the menu and filter options on the right side). The generated ones, which just contain the first letter of the name on top of a colored background are something I wouldn't consider migrating. What I was talking about are the ones uploaded manually by the users. I'm pretty sure that's compliant, because only the underlying software changes, not the context and purpose the data is used for. With your argument migrating the accounts themselves wouldn't be compliant either. btw: Gitea also offers an Oauth2 provider with support for OpenID Connect (https://docs.gitea.com/development/oauth2-provider). That means we could use Gitea as central user management tool for all WFG related developer tools. That'd remove the need for different accounts for different services.

Yes, but in a private repo. Not directly related to the migration, but is code or documentation for the set up of the new infrastructure available somewhere? I find being able to do pull requests for infrastructure as well pretty helpful. I'm in favor of sunsetting Trac and Phab as fast as possible and as long as the links continue to work, by being redirected to Gitea. True. I also disliked the fact you could make the diff private on Phab because that's kind of anti open source to me and moreover it broke the bot as well. If you're gonna have private code maybe don't share it at all... There are valid cases for having stuff with limited visibility at first. I'm thinking about proposed changes and associated discussions which relate to serious security vulnerabilities, where vulnerability details shouldn't be public before a fix is shipped. However, I guess even with everything open on Gitea, we can handle such situation through other channels. Also mind that limiting repositories for users doesn't help much against spam/malicious stuff, if forking existing repositories is still possible, as one can simply replace the content of the forked repository with something else. I'd like to keep trunk for historical/nostalgic reasons, and also because I'd like us to explicitly follow a trunk-based development model. I am open to discussion about that. The vast majority of git repository uses "master" or "main" as their primary branch name. I'd prefer doing so for 0ad as well, as people are used to it. I actually can't remember having ever seen a git repository using a branch named "trunk" as their primary branch. Just recently I was working on a git repository which used a different name for their primary branch and it was such a PITA, as muscle memory (git checkout ma<TAB>) didn't work. What do you mean about surprising? In terms of privacy you mean? (if yes, I tried to be precise in the privacy policy, and people who don't use Gravatar won't have their data sent there, so they are not supposed to complain unless I missed something). For the PoC, getting the profiles from Gravatar allows one to have a sense of the look and feel of the platform and of the community interactions. I wouldn't like to see everyone with generated avatars... For the actual migration, active users will be able to populate their profile, but IMO it would be a bit of a shame to leave all the old members of the community without a face. I'm very happy to see a profile pic associated with janwas or k776 for instance. As Gitea is configured right now, for every request where a profile image is meant to be shown, a request for the user whose image is supposed to be shown is made to Gravatar, unless that user uploaded an own image in Gitea. As these requests happen for every visitor, Gravatar is able to track visitors of our Gitea instance, without them being able to consent to this first. I believe this doesn't comply with GDPR. Upstream Gitea now also ships with OFFLINE_MODE=true by default (https://github.com/go-gitea/gitea/pull/28548), which disables requests to gravatar.com and other external services. Did Phabricator even support Gravatars or were all profile images there uploaded by the users themselves? Maybe it'd be an alternative to migrate the existing profile images from Phabricator to Gitea instead.

Thanks a lot. With OpenGL the GLSL shaders get generated on-the-fly and cached on disk, if they aren't present, aren't they? Would that be possible for Vulkan as well?

I just checked and yes, it's caused by an old save game from 2019. Also no new behavior with Alpha 27/svn, but happens with Alpha 26 already as well.

Are there now instructions how to build the SPIR-V shaders locally somewhere? If not, it'd be great if those could be added.

This is fixed now. If you don't mind, could you please close the PR on Github (or grant me the necessary permissions)?

The "Demo campaign - new maps" campaign doesn't include a single scenario and is therefore unplayable.

When deselecting the "Filter compatible saved games" checkbox in the load game screen a JavaScript error is printed, no matter if saved games exist or not: ERROR: JavaScript error: gui/common/l10n.js line 69 Script value conversion check failed: v.isString() || v.isNumber() || v.isBoolean() (got type undefined) translate@gui/common/l10n.js:69:36 updateSavegameList/list<@gui/loadgame/SavegameList.js:134:35 updateSavegameList@gui/loadgame/SavegameList.js:129:38 SavegameList/this.compatibilityFilter.onPress@gui/loadgame/SavegameList.js:27:51 ERROR: Errors executing script event "Press

The headline "Welcome to the 0 A.D. tutorial." shown at the beginning of the tutorial is broken in Alpha 27 and not being translated. Seems to caused by the introduction of non-breaking white spaces.

I just noticed that there is an additional "Isthmus of Corinth" map in Alpha 27. That means we now have four different ones of these maps: Corinthian Isthmus Corinthian Isthmus (2) Corinthian Isthmus (4) Isthmus of Corinth (2) Can we somehow consolidate or rename them, so we don't have these name collisions? There are surely other Isthmen to name maps after.

I actually would want to improve quite a few strings, however as that wipes out the existing translations on every change, I'm not sure if that's a good idea. That's especially a problem for languages without much translation activity. Yes, the suggested translations also seem to include translations of strings which don't exist anymore. I noticed that only after writing this post. However, that still just a workaround and requires translators to actively check the suggestions, but it's better than nothing of course. I agree with all of that, but getting translations constantly wiped is a pretty big downside in my opinion, so I was wondering if there are alternative solutions which might have less downsides. If there are none, well, that's how it is then.

I recently started to do some translation work for 0 A.D. While I had a high opinion of Transifex before, I quickly realized that it has a major shortcoming: When doing the translations, I noticed that lots of strings which were already translated in the past and do for example show up translated in Alpha 26, wouldn't show up as translated in Transifex. I was quickly able to track that down to https://trac.wildfiregames.com/changeset/27786, which replaced the regular white space in "0 A.D." with a non-breaking one. While a valueable change, that erased hundreds of translations as Transifex doesn't support fuzzy translations (https://help.transifex.com/en/articles/6220794-gettext-po#h_c820bfaa77). That means whenever somebody changes an untranslated string and be it such a tiny change, the whole translation gets wiped out and the translators don't even get the previous translation shown to adapt it. That's really annoying and results in a lot of unnecessary work. So I was wondering if we should look for an alternative to Transifex which does handle that better. Does somebody have experience with other web-based (preferably Open Source) translation tools? Any other idea how we can mitigate this issue?

That just means you're not as good as you think. I suggest you play a few games against other human players using the multiplayer lobby and you'll quickly notice that AI at any level is still quite easy to defeat.

Because of the complexity of modern software, I believe it's utterly important to keep third-party dependencies to a minimum when developing software. One of the worst offenders there is probably the JavaScript eco-system, where you quickly pull in dependencies by the hundreds if not thousands. It's kind of interesting. I'd argue that the vast majority of people are ethical and as corporations consist of people they therefore should be ethical as well. However, once a corporation reaches a certain size, its employees start making unethical decisions (or at least decisions which aren't in the interest of their customers).

I'm really looking forward for the migration to Gitea, as it makes contributing so much easier and as it bundles different functionality (tickets, wiki, code review, ...) it'll significantly reduce the complexity of infrastructure we need. Great work @Itms.

You need an ejabberd server with the proper configuration. Not sure if that'd work on other operating systems than Linux. Setting this up can be cumbersome, but we got https://github.com/0ad/lobby-infrastructure/ which makes it straight-forward to fire up a virtual machine under any operating system to get an environment to test and play around.