Leaderboard

Hi everyone, For a few years now we have pondered whether git would be the right VCS for the development of 0 A.D. One of the main selling points of git is the ability to create numerous branches for parallel development of features and bugfixes. Several popular platforms (Github, Gitlab.com, ...) leverage this to provide a feature-packed development environment, where people can contribute, discuss, review, and test patches. Historically, the development of 0 A.D. has been performed using SVN, which is a bit old... but suits our needs in a number of ways, already discussed elsewhere. We are using Phabricator to supercharge SVN with a review and CI/CD platform, but alas, Phabricator has been abandoned by its developers. In any case, a lot of contributors in the past couple of years have expressed disappointment with the peculiarities of Phabricator. Thus, we have discussed finally moving to git, without any strong urgency or hard opinions on the matter. I have proposed myself to set up a migration path and a new development environment for 0 A.D., and I am proud to present it to you folks today. I have started working on this "for real" more than a year ago, and started dedicating all my "0 A.D. time" (which has been very scarce) on this project at the end of Spring 2023. It is still, unfortunately, very much a work-in-progress, but now is the time to reveal it and receive feedback. Ideally, I would like to collect feedback from the community, finish the CI/CD system, and fix bugs, over the course of the spring, with the aim of performing the actual migration, if the community wishes to perform it, during the summer. As always, delays should be expected. It is worth noting that personal changes in my life/work balance will give me more free time after the summer. Thanks in advance for the feedback you will provide Presentation of the Proof of Concept I am self-hosting the services for the duration of the tests, so that I have full control and do not divert resources from WFG. All URLs are under itms.ovh, which should eventually become wildfiregames.com Email does not work on this Proof of Concept! I have no will to setup email and I certainly don't want to spam anyone with tests. The services are not updated automatically: the full migration takes around 48h and necessitates some human input. The PoC I am presenting was generated from scratch the past two days. I will update stuff from time to time, when I fix bugs or when I'm bored, but don't expect the PoC to follow the actual development of the WFG services. Please test as many things as you want and don't hesitate to try to break things! Now is the time to make sure I didn't forget anything. All the data sent to the PoC will be wiped out whenever I re-migrate the services, and of course whenever the actual migration happens. Please feel free to play around all this. The services (this will be regularly updated) - gitea.itms.ovh The development platform. This is an instance of Gitea, a self-hosted lightweight alternative to Gitlab/Github. If, in the far future, we want to stop self-hosting stuff, Gitea is compatible with Github features to allow for easy migration. The git repository is at wfg/0ad. Commit messages were reformatted, contain the original SVN revision, links to other commits are preserved as much as possible. The HEAD revision is the HEAD of the SVN repo. A currently WIP of the "future" branch of the git repository, adding commits needed for development with git, is at my fork Itms/0ad. All Gitea users were imported from Trac. Since email does not work, if you want to login, shoot me a DM and I'll send you a password. All Trac tickets are imported at wfg/0ad/issues. The Trac wiki is imported at wfg/0ad/wiki. I tried to self-document the PoC as much as possible, so please read the updated pages, especially BuildInstructionsGettingTheCode and BuildAndDeploymentEnvironment. The FAQ is defaced beyond readability because of its formatting peculiarities, work is needed, my apologies to everyone who worked hard on the visuals of the Trac page... - trac.itms.ovh A read-only copy of Trac, upgraded to the latest release. This serves as a reference, and can stay online as long as needed. See below for the redirect tool. - code.itms.ovh A registration-disabled copy of Phabricator, upgraded to the latest version (RIP). All the inactive accounts were deleted, especially the dormant spam accounts. This should stay up as much as possible. We need to keep all the discussions on patches and commits. TODO: I need to find a (possibly ugly) way to disable the upload of new diffs. - svn.itms.ovh The old and new SVN repositories. This holds the current ps repo (which will stop receiving commits after the migration), the audio and art sources (which will keep working as-is), the new libraries repos for precompiled Windows and for bundled libs, and most importantly the new nightly-build repo WIP: This is currently the biggest missing piece, as I am now going to start working on CI/CD, and the generation of the nightly build. Please read NightlyBuild if you want to know how this will work in the (hopefully close) future. - ariadne.itms.ovh Ariadne is a small redirect tool I wrote as a drop-in replacement for Trac or Phabricator when/if we decide to drop them. A lot of links to Trac exist on the Internet. You can follow Trac-like paths on Ariadne to find the relevant content. Each Trac page displays a link to the associated Ariadne path. For instance : A ticket https://ariadne.itms.ovh/ticket/666 A wiki page https://ariadne.itms.ovh/wiki/Manual_Settings A SVN changeset https://ariadne.itms.ovh/changeset/28056 A Phabricator commit page https://ariadne.itms.ovh/rP28056 A file in the Trac browser https://ariadne.itms.ovh/browser/ps/trunk/source/test_setup.cpp Ariadne also provides a nice page for knowing commit correspondence, just use `rXXXX` as path: https://ariadne.itms.ovh/r28056 https://ariadne.itms.ovh/r28000 Enjoy! And see you soon for regular updates

I just did some combat demo huge testing on svn vs a26. Not using vulcan here because of screen tearing issues I reported earlier. a26 - 4 avg fps, lots of stutters. svn - 25 avg fps, no stutters. That's really great stuff to see, so well done @wraitii @vladislavbelov @phosit and more! I noticed that the bodies really make a difference as well, which is why @nani has an option to turn off the bodies in autociv. I wonder if it would be impactful at all to make the sinking animation for the bodies much more coarse, aka updating the dead soldier less frequently. Its not like the animation needs to be ultra smooth, since ppl don't pay much attention to it.

@Itms Glad to see progress was made and we might have an improved workflow in the not so distant future. Appreciated. I wonder if it would make sense to create a subforum for the git migration and keep this topic as a means for informing the community about the general progress. I already see me bringing up various issues which each might warrant a discussion. Putting them into separate threads would help keep some order at least and help avoid duplicate reports to some extent. Or maybe we simply should use trac?

Guess there are many, one with questionable wrapping is fc5518a22b15827c7f4d4410c27dad4c628af8a4 and on that got worse with rev to sha is 9f85b097e11ffac38df23815a62b14bd25925d2d you can't change human nature Needs to be made public before the actual migration so others can verify the migration, but can wait.

https://www.gamingonlinux.com/2024/03/xz-tools-and-libraries-compromised-with-a-critical-issue/ This is a few days late, but if anyone has a rolling release Linux distro make sure you update. That story is actually scary.

Fine, let me add some random findings in short form: default branch name trunk -> main maybe Pascal case generates a link on trac, maybe camel case as well. The migration script ideally filters such broken links. Example: https://gitea.itms.ovh/wfg/0ad/issues/6796 https://gitea.itms.ovh/TracUser should probably be renamed, at least if it's used in future for automation in commit messages patch by, comments by, reviewed by, svn commit id probably should be a block, ie. no empty lines in between might want to rewrap commit messages at width 72, some weren't wrapped at all and some are wrapped poorly after changing svn rev with the much longer commit hash If the underling file system allows sharing extends this should be even less.

Reminder: registration is now disabled on Phabricator. Only currently active users can post those updates. And indeed I forgot to write this in the top message: all the accounts without content were deleted on Phabricator. If you login to code.itms.ovh, you'll see that every possible dormant spam account was deleted. Of course, if the spammer has recently posted, my script will not delete them... But we can get rid of them manually and then we'll be fine.

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.

So gitea, doesn't have anything to mark comments off-topic, but I managed to delete @Gurken Khan's obnoxiously rude comment. I, as moderator, could also edit it. So I guess permissions are working.

You can make a rude comment in this issue: https://gitea.itms.ovh/PoppaSmurf/historyencylopedia/issues/1 The second problem probably is OK because I renamed that file around the same timeframe to Readme.md, so you might have had a glitch around there. (Nothing wrong with @Itms setup, just a qwirk that gitea has.

The technical issue is fairly well summed up by Sam James from Gentoo at https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 A rather good video by Theo discussing the human component of the exploit:

I was willing to comply but didn't see how how I could comment at that URL; clicking around I encountered (I don't know if this is intended behavior.)

I agree, I honestly think that this is OSS Achilles heel, is the bad actor who take value and instead of giving value back demand better support, that can allow even worse actors to take control. There needs to be a way, to allow the developers to get payed for their efforts with still having the coolness of OSS, or else I'm afraid the entire free software experience might break. (I'm not worried about 0 A.D., until Microsoft Amazon and Google use it for an essential part of their infrastructure and don't contribute.)

The story is scary but thankfully it was not found in stable releases of Debian. Here the concerned versions: It’s known that XZ Utils versions 5.6.0 and 5.6.1 were included in the March builds of the following Linux distributions: Kali Linux, but, according to the official blog, only those that were available between March 26 and March 29 (the blog also contains instructions for checking for vulnerable versions of utilities); openSUSE Tumbleweed and openSUSE MicroOS, available from March 7 to March 28; Fedora 41, Fedora Rawhide, and Fedora Linux 40 beta; Debian (testing, unstable and experimental distributions only); Arch Linux – container images available from February 29 to March 29. However, the website archlinux.org states that, due to its implementation peculiarities, this attack vector won’t work in Arch Linux, but they still strongly recommend updating the system.

Hi, this is really interesting, thanks for sharing.