Dunedan

@Norse_Harold: Thank you very much for your contributions to 0 A.D. and its community. I, and I'm sure all other members of Wildfire Games as well, are very grateful for your contributions so far and hope you'll come back after your break to continue to contribute. As @Norse_Harold already mentioned, we'll try out some new approaches to moderation going forward with the goal to make the community an even safer and more welcoming place. If you encounter inappropriate behavior by other community members, which violates the Terms of Use, please let me know. We're also looking for additional volunteers, who'd be willing to help out with moderation. If you're interested in contributing to that, please send me a private message.

I'm already on it. Give me a few more days.

Which public XMPP server do you have in mind for that?

When using the lobby XMPP server, developer communication wouldn't be independent of WFG infrastructure anymore. Having the main communication platform available when WFG infrastructure is down is pretty important from my point of view. We just had the need for that a few days ago.

You also need to ensure this new key is being used when interacting with our Gitea instance. Adding the following to your ~/.ssh/config should do the trick: Host gitea.wildfiregames.com IdentityFile ~/.ssh/wfg

Until you clicked them in the video, I didn't even notice that there are buttons. I believe the design would benefit from making them look more like buttons.

You don't have to fetch upstream for every change. Just do it as often as you'd do "svn up". The only situation where you will need to do it is when you want to merge a pull request and there are conflicts between the current status of the upstream main branch and your feature branch. If there are no conflicts and you merge using the Gitea web interface, you don't even have to rebase manually, as Gitea will handle it transparently for you.

At Wildfire Games we try to create a safe and welcoming space for all players. As everywhere on the internet, this can be challenging. While we try our best to do so, we also rely on volunteering moderators from the community to help us to enforce our Terms of Use. While enforcement of rules is always subject to interpretation, there are some principles which guide the work moderators do: Moderators are expected to be role models and follow the Terms of Use. Moderators must not engage in conduct that would be considered harassment, coercion, or intimidation. Moderators must treat all players according to the same standards. There must be no arbitrary preferential or punitive treatment of individual players. In their role as moderators, they must only use official channels for communication, in particular only the official multiplayer lobby server, the official 0 A.D. IRC channels and the official 0 A.D. forums. Moderators must internally document the reasons and details of corrective actions they take. Moderators must not share details about corrective actions with people other than the involved parties, other moderators and members of Wildfire Games. Moderators must not share personal information about players they learned in their role as moderators with anybody who isn't a moderator or member of Wildfire Games. If you feel a moderator violated these principles or if you'd like to support us with moderation, please send a private message in the forums to @Dunedan. Aside from members of Wildfire Games the current community moderators are: @rossenburg @Palaiologos @MarcusAureliu#s

I have a little addition to that: I just noticed that OFTC offers the same +S channel mode as Libera.Chat. So all of the three mentioned IRC networks would support ensuring users are connected via a TLS-encrypted connection. I also verified that the official web clients of Libera.Chat and OFTC internally also use TLS-encryption when connecting to the IRC server to ensure that people using the web clients can join channels with mode +S.

IRC with enforcement of TLS would be fine for me.

Kind of unrelated, but I'd prefer if we'd only list services run or moderated by Wildfire Games there or make it at least clear which ones aren't official services. A more decentralized structure of IRC networks would've reduced the impact of the Freenode fiasco, but wouldn't have prevented the fiasco itself. To prevent it a different organizational structure than the one Freenode had would've been necessary. I believe that's what changed when Libera.Chat got set up and that the people running it learned from Freenode. However, only time will tell if that's really the case. If the solution isn't going to be Matrix, there can still be an unofficial Matrix room, but official communication should then not happen via Matrix. From my perspective it is, especially if we host the service ourselves. As we want to be able to log conversations between moderators and players, end-to-end encryption would only add unnecessary complexity to that. In principle we don't have to use the web clients provided by the networks, but could set up our own. Whether that makes sense is another question though.

IRC channels have the downside that IRC network operators are be able to read that communication, which certainly isn't optimal, but would be fine for me. Instead of password + kicking everybody else, making such channels invite only would probably be easier. Libera.Chat also offers a channel mode (+S) to only allow users connected via a TLS-encryption to join a channel (Freegamedev supports that as well, as they don't allow unencrypted connections at all). Maybe let's start with that, see how it goes and consider a more elaborate solution later on.

For the use cases we use Quakenet for right now (general chat (#0ad) and development related chat (#0ad-dev) I believe it's rather import not to self-host it, so it is still available in cases our own infrastructure is down. That has been quite helpful in the past already. I'd prefer to continue to use IRC for that, but wouldn't be opposed to use Matrix either. As much as I'd like to use XMPP, it's probably not a fitting choice, as Matrix seems to have bigger momentum nowadays and if we don't self-host it, we can leverage existing infrastructure anyway. Regarding the IRC network, I believe Libera.Chat would offer the most upsides. Most of the regular IRC users are probably there already anyway. As for the risk that something like the Freenode fiasco happens again, I believe that's rather unlikely, because everybody should've learned from it. I consider the risk that Freegamedev goes away much higher. My preference would be Libera.Chat, followed by OFTC. There is also another use case we'd like to have a solution for and that's a real-time communication channel to provide support for players, where moderators and WFG representatives can talk privately with players. In my opinion that's something we should definitely self-host, as the communication there might contain sensitive data, which would just cause additional hassle when being shared with a third-party service. We also want to log these chats to be able to review them for complaints and appeals. A self-hosted solution just gives us much more control over that. Such a solution doesn't have to be a traditional chat solution though, but could in theory also be an existing help desk solution offering an integrated chat. I'd however appreciate if it'd be a light-weight solution, for example a chat plugin for the forums would be probably already be sufficient for that for now. Leveraging existing infrastructure like our XMPP server for that would make sense as well though, as that'd mean we could integrate support functionality easier into the game and use the existing user database for authentication, if we want to do so in future.

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?