Stan`

Interesting. Wonder what's up with the jpeg artifacts. Probably he should have credited us but seems hard on that website

Created https://trac.wildfiregames.com/ticket/6917#ticket

If you're using tortoise SVN that means you're on Windows right ? Then if you use the current SVN repo you'll get autobuilds And for linux once the deps are installed you can use a simple shell script to build everything. https://code.wildfiregames.com/P241

Yeah I meant that because of Ptol they got one. https://trac.wildfiregames.com/ticket/2214 Might be something in

Temple of Apollo IIRC. Regarding the military colony I believe it's analoguous to the ptol civ but I don't remember.

Locked to prevent further spamming.

Shouldn't they be in build/dist/ then ? I don't mind having them here, but it seems unfair considering no other platforms have them. Okay will take a look. Well to be fair it's also duplicated in the code https://code.wildfiregames.com/D2432 MD with images would be nice but it could probably clutter a bit the binaries folder Yeah at some point I went full crazy on it https://code.wildfiregames.com/D4894 TBH though I don't know if requiring people to have them in the PATH would be such a stretch. I guess the fact there is no official release of premake doesn't help. Also sucks that CXXtest seems to be no longer maintained (https://github.com/CxxTest/cxxtest)... https://code.wildfiregames.com/D3119

Okay Since the files aren't ignored yet do you want a PR on the dev repo ? (Also aren't ignored by the surgeon tool)

Another interesting thing that comes to mind for the CI is the tarball for spidermonkey/nvtt/fcollada location, do we prefer having them managed on http://releases.wildfiregames.com/libs/ or hosted on Gitea releases like https://github.com/wraitii/spidermonkey-tarballs/releases/download/${FOLDER}/${FOLDER}.tar.xz (Fromhttps://code.wildfiregames.com/source/0ad/browse/ps/trunk/libraries/source/spidermonkey/build.sh$122 ) EDIT1: The git repo could probably benefit from ignoring the following exe|dll|lib|pdb|zip|exp|ilk|so|a|obj|raw|tar|bz2|gz|xz|suo|bmp|jpg|psd obj,raw,bmp,jpg and psd were never supported by the engine and can probably be nuked alltogether from history There is also *.thumbs.db which is like dstore (windows miniature cache) Any reason we're keeping the bat files ? Shouldn't we provide sh files as well then ? Does it make sense to convert the binaries/readme.txt to readme.md ? Should it be part of the wiki instead ? Then people would stop making PRs to translate it https://github.com/0ad/0ad/pull/37/files https://github.com/0ad/0ad/pull/35 https://github.com/0ad/0ad/pull/27

Sounds good for data minimization. Since Gitea is a bit more popular than trac these days, we'll also have to monitor whether spambots register and how to deal with them. I know @vv221 simply banned all gmail addresses but it's not really an option for us

Sounds fair. +1 on this. The least media of communication the better. Would really help to have a keycloak or equivalent though so having one account on Gitea means you have a forum account as well that would be the recipient of messages if they need to be private for some reason. Would avoid the my repo got deleted and I don't know why situation. Although a deletion process (Eviction issue creation, two weeks repo deletion could work too) Can you send me my Gitea password ? Is it possible to keep the actual registration dates if Trac has them ? Some accounts may not look legit if they have a very recent date of registration I suppose.

Ah good, on Phab it was a bit messy to see all revisions, even the admin user didn't see everything (and had tbh really limited rights for an admin user) Did you look into sending e-mails ? I imagine it should be as easy as Phab, but might be worth testing. EDIT: Any reason trac user appears as an organization https://gitea.itms.ovh/explore/organizations EDIT2: I don't have a strong opinion on it, but the fact Gitea is using gravatar might be suprising to some, IIRC the forum used to do that as well.

This website? https://replay-pallas.wildfiregames.ovh/ Interesting I always thought this ticket had some insight about trac https://gitea.itms.ovh/wfg/0ad/issues/1819 but it seems the discussions happened somewhere else maybe IRL.

Thanks. I'm happy I could get everything to work There is still too much manual input for JS but at least its there. There has been some progress on the doxygen front https://code.wildfiregames.com/D5252 https://code.wildfiregames.com/D5255 Irc the goal was to get rid of trac since it gets completely absorbed in gitea. Then we can just make the domain point to the gitea for some time I guess ?

Interesting your git repo is 13GB while mine was like 6.7GB in bare form, I wonder why that is. Especially since you removed everything in binaries including that 100MB macos exe that was committed once and the history of autobuilded exe + all the spidermonkey tarballs. And nvtt / fcollada In the top bar you could add a link to SVN and Docs.wildfiregames.com I suppose.

I'm not sure you can migrate code comments and whatnot on Gitea.

We do have some website source on Github. I have no idea whether they are used or not, though. https://github.com/0ad/wildfiregames.com https://github.com/0ad/play0ad.com By the way Itms what about the art, art_source and audio subfolders of current SVN ? I think art cannot be publicly displayed due to some content in it.

The snap is built on the ubuntu thingy, not on our servers. By the way with the new vulkan shaders, the shader build takes at least 5 hours on the macosCI, and 1 hour on my M1 mac. + the rest of the time +- 2h Since the flatpack is standalone, that's possibly a lot more time to make a release Trust me, I went for as much automation as I could, and still a release took about 24hours + time to make the trailer

Possibly, although one might argue since we're breaking everything we might do it now instead of later but that's debatable By the way did you find a better irc bot than mine, or should I make mine point to your instance, to test the load ?

What kind of CLI stuff ?

Maybe we disagree on this: for me the moment WFG makes the flatpack official it becomes responsible for it as in all the flatpack issues becomes Trac/Official issues with the inconvenience you know have to check more places. That's why we have tickets for the snap version on Trac. Since no one has flatpack experience here that would have fallen on me, or nobody if I didn't care. Looks good on paper, but how do you trust them ? I met Osomon IRL (That's not foolproof but it helps). If tomorow they bundle a flatpack with a backdoor, is it their responsibility or ours ? (That's what happened with Steam) I had no idea what version they uploaded (and sure as hell wasn't gonna pay 8€ to figure it out)

Probably just me but I liked the idea of naming the repo pyrogenesis instead of 0ad if we ever split things up more so the engine is its own thing. Just thought I'd mention it.

So that means we'll have to keep deleting every single Phabricator spam message manually that are now on commits, diffs and sometimes on personnal profiles while maintaining gitea ? Oh sweet then. 100MB will make it harder to reach the disk size Also means the repo won't grow weirdly and exponentially like it did for me 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... X) Well I did my best.

Maybe you can remove everyone's permissions ? @ShadowOfHassen @Itms might correct me here but I don't think it's good to fork 0 A.D. due to its size. Disk space isn't infinite and IMHO it's much better to only have branch. (Last time I checked every fork added 6GB of files...) Official repos like the community mod and maybe the lobby can go there but having private things sounds bad. Someone ill intentioned could host an entire fork of the game free of charge on the server. @Itms for the CI I had some attempts on my version. It can build stuff and notifiy gitea through api calls but, extracting the correct branch to build was a bit trickier.

https://code.wildfiregames.com/D2936