And now we have git.

[Z-Man]

Added github:
https://github.com/ArmagetronAd

There and on gitlab, in the armagetronad module, I added a bunch of new branches: (lp: not followed by ~ is short for lp:~/armagetronad-dev/armagetronad/) Branch names in bold.

feature-fortress-ai mirrors lp:0.4-armagetronad-fortress_ai which is derived from lp:trunk-armagetronad-fortress_ai. That's the experimental fortress AI. I mostly abandoned it because at one point, merging from the mainline became a nightmare. Now that the branch is converted, I discovered the reason (short version: bzr doesn't handle criss-cross merges very well) and corrected it.

feature-cmake mirrors lp:0.4-armagetronad-cmake which is derived from lp:trunk-cmake. That was a whole other nightmare. trunk-cmake is stacked on trunk-armagetronad-work, but both branches are in different formats. Because both are broken, neither can be upgraded, and fetching a copy failed. Combining them into one non-stacked branch on the lp servers would be possible, for example if lp merge requests could be executed on the servers... but they can't. Luckily, I found a local copy between the sofa cushions.

Let's say my opinion of lp in particular and bzr in general has not improved in the past week. While it was probably bzr-svn that caused the corruption, lp should not have allowed broken branches to be uploaded.

The hack-0.2.8- branches are synced from the relevant famous ap/ct/sty branches. I only tested the plain sty one, it seems to be possible to merge from master with a non-overwhelming amount of conflicts. sty+ct+ap gets 109 by gits count. Could be worse!

kyle gave be some bzr branches to move over from being related to trunk-armagetronad-work or 0.4-armagetronad-work to the new 0.4-armagetronad, namely
lp:~armagetronad-sty-0.3/armagetronad/armagetronad-v2sty
lp:~armagetronad-ct/armagetronad/armagetronad-ct
lp:~armagetronad-ct/armagetronad/armagetronad-ct-ladderlog
The transformed git branches are lp:~z-man/armagetronad/0.4-(old branch name)-unified, the git branches are hack-(old branch name without armagetronad-).

lp:~armagetronad-ct/armagetronad/0.4-delaycmd has become feature-delaycmd.
Looks like a single feature? Should I transform that to a pull request and merge into master directly? I'm just going by the title and the small history at the moment

Yeah, that's a lot of branches. We should probably merge them or abandon them soonish.

I'm currently the only one with write access on github and gitlab. Two reasons for that: I don't know any of your logins there, and I'd like to try the model where only half a handful of maintainers have direct write access and regular and irregular devs alike submit pull/merge requests (to master, not legacy_0.2.8, obv) from their private copies of the repositories. The maintainers' own work would go the same route (already practiced), and ideally, they'd check each other's work. Thoughts? Pull/Merge requests? Maintainer volunteers? No need to hurry, at the current pace, I can do the job alone (And existing devs can always push to bzr, I'm not going to take that away, lp's bzr merge requests are a bit unwieldy)

[kyle]

Thanks for the help on those.
My commits in the github branches now show up as me

I can't believe it's been 9 years since I touched some of these branches.

I think I'll fork the delay command and add some usage to it an create a PR.

I know the zonesv2 branch works, but I think there were still some issues with it.

[Ratchet]

For what it's worth, I've always been quite interested in "tinkering" with the code to see how it works and to learn how to make changes. The old way of cloning the repository was very non-intuitive for an outsider, and to be honest I don't even think I could do it in less than 10 minutes today. SVN/bzr/whatever it was just didn't feel very user-friendly to me and it was intimidating. Now that it's hosted on GitHub, something I am familiar with and use myself, I feel much more empowered to obtain the code and to contribute. Even today, when I no longer play the game, I'm intrigued and interested in cloning the repository to see if I could help out.

One thing that I've always struggled with is the seemingly insurmountable errors that come up when trying to build. I realize that I was lacking maturity and problem-solving skills in my adolescent years, but it was a quite complex process to get the game built and running. If someone would be so kind to set up a VM or something and record a video doing a 0-to-100 tutorial on building from source (including obtaining the relevant tools), it would really help someone like me who just doesn't know what tools to use and how to set them up. The tool setup process feels like 80% of the battle for me.

I realize this is a wishlist item and no one really has the time to do it, but I figured I'd throw it out there.

[sinewav]

If someone would be so kind to set up a VM or something and record a video doing a 0-to-100 tutorial on building from source (including obtaining the relevant tools), it would really help someone like me who just doesn't know what tools to use and how to set them up. The tool setup process feels like 80% of the battle for me.

What OS are you running? I've been on Ubuntu the past decade and building has always been straightforward, simply running the commands at the very bottom of the wiki page (Get Dependencies) This last time I built from source, just a few weeks ago, I had a problem with SDL and got pretty much immediate feedback on these forums and was playing Arma in no time.

I think the general way to build Arma (or most things) is download the source, change into that directory, bootstrap it, then run configure. The output of configure will warn you of missing libraries. If everything is OK, run the program make to compile. Sure there are a lot of things that can go wrong, but that's the fun part, right!

If you're on Ubuntu I can make a video, but I barely know what I'm doing, and I've talked to you enough times to know you're smarter than me.

[Ratchet]

Right, sorry, I forgot that ArmagetronAd has a large unix userbase

I'm still a Windows pleb. A demonstration in Win10 would be ideal. I remember having to download Code::Blocks with MinGW and fight a few hundred build errors to get everything going. I think I actually succeeded once, but I'm pretty sure that I had to comment out some things that were probably critical just to suppress the errors. Performance also kinda sucked -- I, too, had SDL issues somewhere along the way.

[aP|Nelg]

The old way of cloning the repository was very non-intuitive for an outsider, and to be honest I don't even think I could do it in less than 10 minutes today. SVN/bzr/whatever it was just didn't feel very user-friendly to me and it was intimidating. Now that it's hosted on GitHub, something I am familiar with and use myself, I feel much more empowered to obtain the code and to contribute.

`git clone` vs `bzr branch` vs `svn checkout`

Also, you can grab the source straight off both launchpad as well: On one of the "Code" pages (ex 0.2.9-armagetronad-sty+ct+ap) scroll down and click on the latest revision, then click "Download tarball".
Or, if you don't want to scroll, click "Browse Files" > "View Revision" > "Download Tarball"

I'm still a Windows pleb. A demonstration in Win10 would be ideal. I remember having to download Code::Blocks with MinGW and fight a few hundred build errors to get everything going. I think I actually succeeded once, but I'm pretty sure that I had to comment out some things that were probably critical just to suppress the errors. Performance also kinda sucked -- I, too, had SDL issues somewhere along the way.

You can probably cross-compile (using mingw) with Cygwin or the Linux Subsystem for Windows as well, although I haven't tried it yet.
Also, random sidenote, the steps to follow are pretty much the same across every Windows version, I would guess NT 4 and newer.

[compguygene]

Added github:

feature-fortress-ai mirrors lp:0.4-armagetronad-fortress_ai which is derived from lp:trunk-armagetronad-fortress_ai. That's the experimental fortress AI. I mostly abandoned it because at one point, merging from the mainline became a nightmare. Now that the branch is converted, I discovered the reason (short version: bzr doesn't handle criss-cross merges very well) and corrected it.

Well, I am very excited! I will be setting up my Fortress Vs Bots server again. I also will build a new sumo server. First I have to setup my new vps for that.....

[Z-Man]

Does anyone have objections against declaring our GIT branches now the one true source? An issue has cropped up, that's why I'm asking.

At the beginning of the year, Python 2 fell out of support completely. The original BZR implementation is based on Python 2, and it does not look like they're going to upgrade ever. The git-bzr bridge we're using is tied to the original BZR and equally stuck. So the days of our bzr/git syncing working are very much numbered. Nothing has broken so far on the sync machine and I'll keep it going for as long as possible, obviously.

There now is a fork of bzr called Breezy or brz, ported to Python 3. I noticed all this because Arch replaced bzr with it, breaking my local git-bzr. I don't think it does us any good here, git-bzr would need to be adapted to it.

[Monkey]

So does this mean the end of Launchpad too?

I know I'm not a developer but I'd be happy to replace BZR/Bazaar in favour of Git; I think Git is the way forward. Even OpenBSD are creating their own client that interfaces with git repositories (it's called "GoT" aka "Game of Trees"). If this change does happen then links on our website will need to be updated. All in all, it's a yes from me.

[sinewav]

As a non-dev, this is a non-issue. All I care about is getting the source code. Whether I type bzr co or git clone makes no difference. Launchpad and bzr seem dead anyway. Arma is the only thing I get from there. I think all the Linux PPAs I use are self-hosted. Do what you want!

[Z-Man]

So does this mean the end of Launchpad too?

Probably not, they also support git repositories. And they could technically switch to breezy.

[Light]

Does anyone have objections against declaring our GIT branches now the one true source? An issue has cropped up, that's why I'm asking.

I think this should have happened a long time ago. Maybe continue uploading releases for a while, but GIT is the way to go. Of course, I'm not a dev here, but I have worked on projects using both options, and BZR feels outdated.

This is all just opinion based, but I see no benefit to keeping both options.

[Monkey]

@Z-Man
Sorry, I wasn't clear about Launchpad. I meant are *we* leaving Launchpad?

[Z-Man]

Ah. For project management purposes, yes. I think we effectively already left Launchpad and slipped into the "Z-Man handles all merge/pull requests" model. That's expandable, of course.
I'd still be using Launchpad's services; I find the PPA build service quite essential and hard to replace with own infrastructure (though there might be just a docker based system you can slap onto any old server, haven't checked).

[Light]

(though there might be just a docker based system you can slap onto any old server, haven't checked).

That's always my assumption. (:
https://hub.docker.com/r/crashvb/reprepro/

I see no certified images for this, so if that's a bother, we'd have to just make one, but shouldn't be too difficult. I didn't look, but we could probably recycle most of that dockerfile and use the certified nginx release.