TripleA development
-
@frigoref Unless I'm missing something, I don't think currently we are even clear if and how (and where: here or GitHub) anyone is tracking feature requests at all, really.
This is how feature requests used to be tracked:
https://forums.triplea-game.org/topic/182/guidelines-and-feature-request-list -
@rainova said in TripleA development:
@magicstyck @djabwana If we work on accelerating the PR process, how much time would you then volunteer to TripleA improvements?
Like most devs, my time fluctuates based on work and family priorities. I could reasonable volunteer time of 3 hours a week or more.
What would be required to make these improvements worth the time for you?
PR reviews in a timely manner would go a long way. PRs that sit for long periods of time and never merge are annoying. PRs that are for documentation changes should be reviewed quicker than technical PRs.
Also not holding up the merge of PRs which are purely technical with non-technical objections. For instance: rehashing over and over the wording of comments or objections that it might affect something completely unrelated to the PR.
Would you be satifsfied with purely technical improvements like fixing the serialization and cleaning up the code base?
Absolutely. The goal, for me, is improvement of the software. Cleanup, bug fixes, closing gaps, is all part of that.
Would you expect that we can marshal the required dev capacity by merely improving the dev process?
Yes. In my experience, when the process is easy to adopt it is easier to inspire more people to help out.
Would it be worthwhile to discuss other ways to make development more attractive? If so: Would it suffice to adress the developers currently active in the TripleA community or should we try and recruit developers who are currently not part of the TripleA community?
It's always beneficial to discuss ways to attract others to help out, whether they are part of the TripleA community or not. It sounds like the current developers are burnt out and need help to move things forward. If someone is offering to help, whether they are in the community or not, let them help.
Making development more attractive comes as part of the cleanup. 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.
-
@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
"You should never have told me horses sleep standing up, it gave me a mental block." - Mister Ed
-
@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.
Don't always trust TripleA when it comes to rules questions. Know the rules before you start … and better check what TripleA has done.
-
@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!
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login