TripleA development
-
@rogercooper
Could we get an overview about the contributing people and their core area on the github Wiki?
https://github.com/triplea-game/triplea/wiki/ContributorsWould be nice if people could make their entry there so we have something that we can organize ourselves better.
@LaFayette Maybe you can list all users with merge rights? -
@frigoref curious why i'm labeled inactive on your list
-
@frigoref
Also what do you mean by "area" ? -
-
I don't recall I've ever known what I'm supposed to do if anything.
-
It has to be easy for a developer to setup an environment quickly and able to debug what is happening. If they have to jump through a thousand hoops to get started, your going to lose them.
- Have you tried to seek out help about any of these hoops?
- Which of these hoops have you had to jump through specifically?
@LaFayette Maybe you can list all users with merge rights?
https://github.com/orgs/triplea-game/teams
The team that allowed for 'write-access' was 'secret'. I updated it to be 'public', it should be visible now.
The main areas of TripleA are:
- System Admin
- Make sure the systems are running
- Deploy software changes to the systems
- QA
- proactively looks for bugs in the latest tripleA release. Specifically, they don't look around in just one area, but they try to execute every code path in TripleA possible, they click every button, every toggle, make every movement scenario and combination to validate that everything works correctly
- Developer
- submit PRs on github
- Development Maintainer
- Reviews PRs, they are the ones responsible for fixing problems post-merge
- Fixes pre-release problems (other peoples bugs)
- Fixes major live problems reported to the project
- Project Maintainer / Leadership
- communicates about the project & project priorities
- arbitrator
- Bug Triage / Issue Maintainer
- try to help people through issues
- ensure that issues have full information or close them
- full information being things like "which map", creating a save game at the point of problem, etc.
- Map Admin
- maintains map repository, ensures maps are well cataloged and made available for downloaded
- Map Contributor
- Forum Moderator
- Lobby Moderator
- Graphics/Designer
- Treasurer
You propose a grand re-write. Those tend to go south and never wind up completed. The goal of 3.0 would be to make the system more modularized. As an analogy, instead of having one giant frankenstein monster, 3.0 would make that monster more like Mr Potato head, where we could more easily swap out the arms and legs. We would still have some large problems to solve, but though would be an order of magnitude smaller and generally much more tractable.
There are circular object references that break serialization to XML or JSON. The plan for save game is to only save the game data changes to disk. To do this we need to change the guts of TripleA to be able to dynamically build a 'game data' object using only a given 'map ID' and list of game data changes.
How much PR pain do you think there would be on a second pull request compared to the first one? IIRC a lot of your issues were due to being a new contributor and I don't think would have had the same issues on a second or subsequent PR.
Second, how do we fix review issues? I do recall there was some major problems introduced after several updates, problems which should not have happened. This is very salient because I think around 70% of all PRs introduce at least one bug. It then goes on to the maintainers to find and fix these. Hence, a first time code-submitter gets the worst of all worlds, issues that come up becuase they are not familiar with the project, and extra scrutiny because it's more than likely problems will be introduced and it's a goal that any contributor introduce zero problems. If the contributor agrees to be a maintainer, then the bar is lowered, otherwise each change needs to be well done and 100% correct (this is software, it must all be correct).
So, if we use the reasonable 3 hours per week standard, and it takes a good hour to review code, and another 10-20 minutes to test it; seemingly there is not much time to do that more than once or twice a week. How can we improve turn-around times in this kind of scenario? My thoughts were that we continue to add more automated review checks and continue trying to be unrestrictive about smaller items (perhaps you should have seen some of the blockers from earlier on in this project if you complain about keeping comments in sync with the code as too much of a a details as that).
-
@lafayette said in TripleA development:
It has to be easy for a developer to setup an environment quickly and able to debug what is happening. If they have to jump through a thousand hoops to get started, your going to lose them.
- Have you tried to seek out help about any of these hoops?
- Which of these hoops have you had to jump through specifically?
When setting up my dev environment for this project over two years ago, it was a lot of trial and error to get it working. Documentation was old or flat out incorrect. When analysing the code base to work on a change, there are little to no design documents to help answer some of the basic questions. Over those two years some of those documents have started to appear but still large gaps exist. For instance, the legacy documentation lays out a design that the current software begins to deviate from. How much still applies? What does not?
Infrastructure code, which should be stored in separate repos, is in the root tree of the application causing bloating and confusion of what is import to running the code and what is not. I've worked with a lot those technologies so I know what to ignore as "not needed" when working on the code base. New contributors to the project will not.
Any change to the code proposed as an issue with how TripleA applies, even if it only affects the supported rulesets, is met with hostility based on "this might affect my game which doesn't use that ruleset", "might break game saves", and "shouldn't be considered because I don't agree with the Larry Harris accepted interpretation of the rule". There wasn't even a PR for the fix yet, just a conversation. https://github.com/triplea-game/triplea/issues/9067
No credit for work done. I helped out on a PR regarding Docker and NodeBB. I wrote the container and the documentation for it. I got a "thanks" and no credit on the merge. If you check contributors for that work, my name doesn't appear yet here is all my work. What does it take to be considered a dev or a contributor for this code base?
Original conversation: https://github.com/triplea-game/triplea/pull/7799
PR of the work: https://github.com/triplea-game/triplea/pull/7906No response or direction at times. Conversations just die. I was loading a skin in the current release (2.5) and ran into an issue that has been open for awhile. I decided to help out on fixing it. I did the leg work, got stuck, reached out got a little help. I got a random statement about skin being different in 2.6 than 2.5. I asked if 2.5 is open for patching. Crickets. https://github.com/triplea-game/triplea/issues/8102
So yes, hoops. Hoops that discourage participation of offering up PRs to fix issues.
Second, how do we fix review issues?
I would suggest not holding up PRs based on non-technical issues. For instance, this PR (https://github.com/triplea-game/triplea/pull/9963) was not merged for over 2 months because of a disagreement on adding a comment line which could have really been added later. Was that comment line truly worth holding up a technical fix that was agreed would bring consistency?
I do recall there was some major problems introduced after several updates, problems which should not have happened. This is very salient because I think around 70% of all PRs introduce at least one bug. It then goes on to the maintainers to find and fix these. Hence, a first time code-submitter gets the worst of all worlds, issues that come up becuase they are not familiar with the project, and extra scrutiny because it's more than likely problems will be introduced and it's a goal that any contributor introduce zero problems. If the contributor agrees to be a maintainer, then the bar is lowered, otherwise each change needs to be well done and 100% correct (this is software, it must all be correct).
What does it take to agree to be a maintainer? What is the process? What does it entail?
-
@magicstyck said in TripleA development:
Any change to the code proposed as an issue with how TripleA applies, even if it only affects the supported rulesets, is met with hostility based on "this might affect my game which doesn't use that ruleset", "might break game saves", and "shouldn't be considered because I don't agree with the Larry Harris accepted interpretation of the rule". There wasn't even a PR for the fix yet, just a conversation. https://github.com/triplea-game/triplea/issues/9067
Welcome to the frustrating world of rules issues likely not going to be fixed at any time.
https://forums.triplea-game.org/topic/1549/rules-issues-with-the-triplea-engine/It is of course totally fine to discuss those issues. And they must be discussed, as their interpretation in some cases is not crystal clear or need 'official' clarifications. Sometimes the rules are poorly or incorrectly implemented in TripleA (for example v2) - but people are so used to the misconceptions that they think it is correct. Sometimes the misconception intentionally is even part of maps, what is fine, too. It is no problem that not-rules-compliant features are part of the game, as long as people are aware of that, and as long as those are optional.
The problem is that after the discussion of rules issues no one really cares to implement changes.
Not an accuse to anyone - just stating a fact. Priorities lie on whatever but not on fixing rules issues. That had been different in the past (years ago). But currently it is how it is.
That you must have in mind when bringing up rules issues.
Of course all of this and the other things you stated is just the consequence of a simple fact: Those people currently regularly active here on the forum (or discussing for example rules issues at Github) are (apart from a few exceptions) usually people that do not have the ability to work on the engine code or - in case they have - do not have the time or the needed interest in certain special aspects of the game(s) / the engine.
That is why we are world champions in discussions - but fail to fix or implement a lot.
-
@magicstyck Issues like the https://github.com/triplea-game/triplea/issues/9067 you mentioned are not pointless. They are waiting for someone who knows the rules (like @Panther) to review them.
Not much else to do when the rules are not clear to everyone the same way.
Unfortunately, we don't have any developer with a deep understanding of every rules-set, as far as I know.
-
@cernel And if one would have gone ahead making the proposed changes without checking the rules very carefully, I would say chances are doing more bad than good.
On top of that, you must also consider supporting custom games. TripleA is not all about un-original work.
-
@panther said in TripleA development:
Of course all
Can I assume that the list in https://forums.triplea-game.org/topic/1549/rules-issues-with-the-triplea-engine is maintained well and they are meant to have all the same label "Impact: Bad Game Rules" on github?
If so, can you help to prioritize them?I absolutely understand the frustration that is going around. However, I would hope that you all are still willing to assist in
(1) structuring the issues we have
(2) organize ourselves, so responsibilities and current status,
so we can get a clear overview and try to tackle the issues according to their priority.
My hope would be that we get to a point where we can onboard new developers (responsibility with the dev team) and hand them a sorted (!) list of issues (responsibilities lies with moderators assisted by the end users) from which they can choose and provide fixes. -
@magicstyck Why is there such a big deal about changes breaking saved games? If you start game, keep using the same version until you are done.
Breaking existing XML is more of an issue, but we have done it before, and I personally fixed many mods with a simple batch file.
So please, feel free to go ahead with refactoring code and don't worry about covering every obscure A&A rules case.
What does need to be done to discuss major changes before they are made. 2.6 did major changes like deprecating mapName and Notes with little discussion.
-
@frigoref said in TripleA development:
Can I assume that the list in https://forums.triplea-game.org/topic/1549/rules-issues-with-the-triplea-engine is maintained well and they are meant to have all the same label "Impact: Bad Game Rules" on github?
If so, can you help to prioritize them?In general you can assume that. What I don't know is - as PR do not always refer to issues - whether working on other details maybe had any impact on them. What I will do is check the labels again - and of course I will help to proritize them. There are serious issues and minor issues, that's for sure.
-
IMHO we should not push forward 2.6 as long as major issues such as the MARTI-issue and the broken-PBF-nodeBB-issue are not fixed.
-
@panther can you please also label the issues you consider 2.6 blocking issues?
Do you need help for this?Is there anyone interested in assisting panter?
-
-
I've been looking at the FeignException 404 on map listing. I know what is happening and why. I'm working on a test and coding a fix for it. I should have a PR in by the end of the weekend. I can help work on any other blockers after that.
All related issues:
https://github.com/triplea-game/triplea/issues/10023
https://github.com/triplea-game/triplea/issues/10053
https://github.com/triplea-game/triplea/issues/10079 -
@magicstyck sounds great! Many thanks for taking this one up!
-
@magicstyck Let me know if you can get to the point that mods can be downloaded using 2.6. For now, I am doing my updates to the map repository using 2.5.
-
@frigoref @Panther @RogerCooper @LaFayette
@magicstyck said in TripleA development:
I've been looking at the FeignException 404 on map listing. I know what is happening and why. I'm working on a test and coding a fix for it. I should have a PR in by the end of the weekend. I can help work on any other blockers after that.
When I posted this afternoon, I thought the issue was a broken endpoint in the spitfire-server, the code that runs the lobby. I have since confirmed locally, that is not the case. When I spin up the 2.6 lobby, I'm able to run a GET request on the /maps/listing endpoint without issue.
curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer oijsad80lksjdflsdflk" -H "System-Id-Header: 1234567890" -H "Triplea-Version: 2.6" -v http://127.0.0.1:8080/maps/listing * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > GET /maps/listing HTTP/1.1 > Host: 127.0.0.1:8080 > User-Agent: curl/7.64.1 > Accept: application/json > Content-Type: application/json > Authorization: Bearer oijsad80lksjdflsdflk > System-Id-Header: 1234567890 > Triplea-Version: 2.6 > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Thu, 17 Feb 2022 05:39:42 GMT Date: Thu, 17 Feb 2022 05:39:42 GMT < Content-Type: application/json Content-Type: application/json < Vary: Accept-Encoding Vary: Accept-Encoding < Content-Length: 214 Content-Length: 214 < * Connection #0 to host 127.0.0.1 left intact [{"downloadUrl":"http://download-url","previewImageUrl":"http://preview-image","mapName":"test-map","lastCommitDateEpochMilli":1644988237583,"description":"map description","mapTags":[],"downloadSizeInBytes":1024}]* Closing connection 0I logged into the postgres database locally and deleted the record in the map_index table of the lobby_db (where data returned above comes from). This confirmed that if the table is empty, the /maps/listing endpoint does not return a 404. It returns a 200 and an empty JSON array.
curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer oijsad80lksjdflsdflk" -H "System-Id-Header: 1234567890" -H "Triplea-Version: 2.6" -v http://127.0.0.1:8080/maps/listing * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > GET /maps/listing HTTP/1.1 > Host: 127.0.0.1:8080 > User-Agent: curl/7.64.1 > Accept: application/json > Content-Type: application/json > Authorization: Bearer oijsad80lksjdflsdflk > System-Id-Header: 1234567890 > Triplea-Version: 2.6 > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Thu, 17 Feb 2022 05:45:03 GMT Date: Thu, 17 Feb 2022 05:45:03 GMT < Content-Type: application/json Content-Type: application/json < Vary: Accept-Encoding Vary: Accept-Encoding < Content-Length: 2 Content-Length: 2 < * Connection #0 to host 127.0.0.1 left intact []* Closing connection 0According to closed PR that introduced the change (https://github.com/triplea-game/triplea/pull/9940), if I pass the Triplea-Version header then nginx should proxy me to the correct lobby. If the new nginx config is deployed, then it should read that header key and send me to the 2.6 lobby. If it isn't, then it will send me to the 2.5 lobby on every request. I sent the key with a value of 2.6 and was returned a 404.
curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer oijsad80lksjdflsdflk" -H "System-Id-Header: 1234567890" -H "Triplea-Version: 2.6" -v https://prod2-lobby.triplea-game.org/maps/listing * Trying 173.255.225.250... * TCP_NODELAY set * Connected to prod2-lobby.triplea-game.org (173.255.225.250) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=prod2-lobby.triplea-game.org * start date: Jan 30 23:55:24 2022 GMT * expire date: Apr 30 23:55:23 2022 GMT * subjectAltName: host "prod2-lobby.triplea-game.org" matched cert's "prod2-lobby.triplea-game.org" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7ff154810000) > GET /maps/listing HTTP/2 > Host: prod2-lobby.triplea-game.org > User-Agent: curl/7.64.1 > Accept: application/json > Content-Type: application/json > Authorization: Bearer oijsad80lksjdflsdflk > System-Id-Header: 1234567890 > Triplea-Version: 2.6 > * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 404 HTTP/2 404 < server: nginx/1.18.0 (Ubuntu) server: nginx/1.18.0 (Ubuntu) < date: Thu, 17 Feb 2022 06:27:01 GMT date: Thu, 17 Feb 2022 06:27:01 GMT < content-type: application/json content-type: application/json < content-length: 43 content-length: 43 < * Connection #0 to host prod2-lobby.triplea-game.org left intact {"code":404,"message":"HTTP 404 Not Found"}* Closing connection 0So the issue is not a code problem but a deployment one. One of two things is incorrect in the production environment:
A: The nginx web server does not have the latest config deployed to it to properly proxy requests to the correct lobby.
B: The 2.6 lobby as a whole, has not been deployed or is setup but running a 2.5 lobby.
Until the 2.6 lobby is deployed and the nginx web servers config is updated, all 2.6 client requests for maps are going to return 404.
This card I found on the Project schedule (https://github.com/triplea-game/triplea/projects/25#card-75012745) suggests that the 2.6 lobby has not been deployed but can be at any time. If this gets deployed, we can close 6 or more issues and be closer to releasing 2.6.
closed Header redirect/lobby variable port number #9940
