TripleA development
-
@MagicStyck , re: chats falling off.
My hope is that anyone opening an issue would 'own' that issue and try to drive it to closure. EG: every month, mention, "hey, this still needs X from
@Y" Invariably that does not happen, instead maintainers (eg: me), has to re-read from the start the entire issue to understand what is going on. This does not scale.We had 'stalebot' previously to outright close issues where this was not happening and where issues were just getting old. Stalebot was incredibly unpopular, and even the stalebot message of "hey, this is being closed, please re-open and add a comment of what needs to be done" was routinely ignored (and instead there was quiet and sometimes very loud griping about issues being closed by stalebot).
This is overall not a problem I can really readily solve. I'm open to ideas on how this could be better. I'm just reminded after seeing some issues that are still open and not moving anywhere, further compounding the problem that issues are getting "lost". Perhaps this is argument for us to bring back stalebot even but close issues after a mere 2 weeks if they are not labelled as bugs. I don't really have any better ideas, at this point the old issues I'd say are hurting us as well as causing ill-well with the crickets. I barely have time to even respond to this forum thread, let alone everything else..
-
@lafayette said in TripleA development:
Which OS are you using? If other than Linux with IntelliJ, then we have an active need for that configuration to be well documented. I am personally frustrated when any developer sets something up for themselves and does not document how to do so, leaving the rest of the team to independently re-discover that configuration.
I use a Mac and Linux for development. I have Windows 10 machine (primarily for gaming). I'll have a look at the current OS setup documentation in the repo and see what I can add given my environments.
The legacy design starts to fall apart when details of multiplayer and bots were included into the code base. It's historical reference, has been for around a decade if not longer. The reference is maybe useful to know which principles the original authors were going for.
Is this a hoop per-say? Should we delete the legacy documentation outright? Archive it somewhere? Add an explanation of why we still have it at all?
Please don't delete it. I found it very helpful in seeing what the original intention was. The gap is where it is now and where it is going. I'll take a crack at organizing the legacy docs so the knowledge doesn't get lost but it's considered the source of truth for development.
If the lack of attribution on github is due to 'squash-merges' instead of 'rebase-merges', the attribution aspect would be a compelling reason to change merge strategy. I'm amenable to any changes that would fix this.
That would do it. I removed the 'squash-merges' and 'rebase-merge' from all my professional teams specifically for this reason. The contributors section is taken from the master/main branch as feature branches are deleted after merge. It reads the contributions from the history of that branch. If your name is on the commit, you appear in the contributors section. You can browse that section and drill down into the exact commits a contributor has made. Squash and rebase rewrite the history of the commits to condense them down leaving only a single person on the condensed commit. Echos are left behind where you can git blame a file seeing that someone else made a commit at the same time as the person listed on the commit but you can't tell what they did as the hash associated with their commit is gone.
With respect, I'd like to point out that is not accurate. It took over a month for me to look at the PR at all. The overall delay was constrained by my availability, not by any disagreement. When I first looked at that PR, I left a comment that I hoped would be quickly addressed and avoid a very minor element of technical debt. When I got back to the PR weeks later, I saw their was presumably a misunderstanding and a disagreement based on a faulty premise. I then merged the PR. I did not insist the disagreement be hashed out further before merging.
Fair enough. I had the intention wrong. I'm sorry. Thank you for clarifying.
-
@LaFayette thanks for closing my PR as you mentioned. In that case, I was purposefully trying to sidestep all the things that we've been discussing here by making it totally "under the radar" - no javadocs, no comments, nothing- just actually making the code the way it should've been from the beginning (IMO) since that data structure is both a list (reading the list of points from the file) and a "lookup" structure (to find the point associated with the name). In other words, the burden falls on the original developer to comment why
LinkedHashMapwasn't used and original order was lost, since that would be the default assumption/expectation.With all love and respect to @Cernel (he always has good points/ideas/feedback/context, but despite that...) it was really frustrating to have my intentionally minor/secret/quick/minimally-invasive PR get mired down in long discussion. So I see both sides of these issues- ease of contributing vs. burden on maintainers. I think it's just that TripleA has become an enterprise-level codebase (there are some great and powerful features in there) but maintained by hobbyists and we all have "day jobs"...
For anyone who has invested time in it, thank you! it's been a great venue with keeping up with old friends I used to play A&A with in high school.
-
@lafayette said in TripleA development:
Though, the prerelease server had been suffering from disk space issues; this caused disk to fill up and the database then to crash and be unavailable for any requests to it thereafter (even if disk space were then freed). To fix this, the DB needed to be restarted and this was being done for some time.. I recently found, about a week ago, what looks like old map files that were taking up around a third of the disk. We have the bots download all maps, all maps are about 5GB or so, and there was an extra copy of this floating around. Without that extra copy we should have breathing room and the problem gone.
Oof. Double whammy. If you need a hand, I professionally live and breath this type of architecture and services. I updated my profile with my LinkedIn if you need referrences.
The version change is a red herring; it should have been fixed for the config panther was using for previous 2.6 versions as well. It just so happened it was fixed after downloading a new version. If there really is a difference between versions downloading from prerelease explicitly, that would be very interesting.
No difference in the 2.6 versions. I confirmed that this afternoon.
Side-bar, is there anyway we can move this 2.6 launch related conversation to the 2.6 conversation thread? https://forums.triplea-game.org/topic/2999/2-6-release-getting-close-need-volunteers-to-help-beta-test-2-6
Absolutely.
-
@magicstyck hahaha if we all joined up and started a software company together, it would be amazing
-
@djabwana said in TripleA development:
@magicstyck hahaha if we all joined up and started a software company together, it would be amazing
:beaming_face_with_smiling_eyes:
That made me laugh out loud :face_with_tears_of_joy:
-
What about issues where there's nothing more the person who opened it can do; and the only people who possibly can address the issue are very busy (eg you)? I mean, I tried to push the long-standing problem affecting the Global map unit transfer in lobby bots; but you're very busy, and poking you repeatedly doesn't change that you're busy, and it's not something that can be fixed by someone else since it appears to be about deployments.
I just don't see any good ways to handle it; sometimes priorities have to be made and certain issues will just get put on indefinite hiatus because the only people who can address them are busy.
-
I feel like we're all mostly at least on the same page. Some problems certainly remain, but our perspectives are more aligned now - that is valuable.
I think @MagicStyck & @frigoref should gain system access to at least the pre-prod environments if not also prod so that they can help there.
I do strongly prefer having squash merges for a better history, and certainly at least rebase merges so that the history is linear. We have had several bugs where we were only able to track the problem down after bisecting the history. If the history were non-linear, we would no longer be able to do that. Some problems are amazingly subtle, I'm sure we would have had to roll back a years worth of commit if the history were non-linear. Perhaps the answer is to more readily give write access to those who want to contribute more than a single PR. This way those that are doing the bulk of a PR can be the one doing the merge and get attribution. As a complement and/or alternative - perhaps in the release notes we could explicitly mention the contributors since they may not appear in the git history properly.
-
@zlefin There is a 'high impact' label or something like that to note issues that are more significant. Adding that label where appropriate would presumably help. I've been avoiding a bit having a lot of priority labels lest we fall into the trap of adding a lot of "work about work" that is not actual 'work'. Suddenly labeling and assigning priorities becomes a job, which is not very helpful if all we do is bicker about priority and shift priorities around without actually accomplishing those priorities. We also run into the problems of "important to me, but not you, so where is the priority?"
If a map is majorly broken, eg: the unit transfer functionality which I think has broken on just about every release over the last 5 years, is a major feature of some maps. It would rank pretty high to fix that.
-
Well, with global it's only moderately broken; the problem only applies in lobby bots, and most people are satisfied with fixing it via using edit every round. It's infrequent enough that doing so isn't too onerous. It does make TWW very hard to play in lobby bots, as there's alot of unit transfer triggers in it. Should I apply some label to the pertinent bug report on the matter? Since it's something that afaik only you can address, you should be the one deciding on the priority level.
-
So far as taking care of problems goes, there are a few map issues/PRs here that could be looked at, and several can probably be merged. They may not be in the main game, but they do make issues in the main game when they have problems.
-
@ff03k64 I don't understand "They may not be in the main game, but they do make issues in the main game when they have problems". How can they "make issues in the main game", when they are not in the main game?
Should a rule guru look over them first before a developer starts? -
@LaFayette Can you create a guide on how to test such bot issues? I would have no idea how to analyze them.
-
@beelee, @Panther , @RogerCooper
Would you please provide your comment on the to-be TripleA issue process flow I have tried to draw?
-
@frigoref this is awesome! but I think you mean "Rules clear?" "No" goes to Guru
-
What @djabwana says.
Also I stumble a bit over the "rules clear?" question.
In more than a decade of rules discussions I have learnt that despite rules might be "clear" to someone that "clearness" must not necessarily cover reality.
So maybe it would be a good idea that someone familiar with the rules looks at every issue that touches rules questions (what actually has been practiced for years, IIRC).
-
@frigoref Good basis to clarify who should do what!
If you want to store graphs in a markdown (.md) file, you might want to use mermaid or PlantUML, see https://www.jetbrains.com/help/idea/markdown.html#preview
-
@rainova I have played around with it a bit, but it I think the repeat loops are always on the wrong side causing the diagram flow to be more confusing that it actually is:
-
@frigoref You should add an intermediate step after the "rules clear?" part.
I think the current label is almost worthless as it is usually added without clarifying what needs clarification, so it is basically an encouragement to add more and more text to the issue trying to catch whatever is being unclear to whoever.
If a rule is not clear to everyone, the person that feels so should clarify exactly what needs to be clarified and then you can actually clarify the rule, so you need an intermediate thing between the "rules clear?" and "clarify rule" steps.
Moreover, the "clarify rule" step should direct back before the "rules clear?" step, because having clarified a rule doesn't imply that is actually fully clarified. So the clarify rule should direct to "update issue".
Moreover, I've no idea how an issue can be complete if it is not clear, but maybe you mean that just satisfies the minimal requirements of reporting. I think you should clarify what you mean by "complete".
-
@cernel You are right this process flow is not detailed enough for what exactly to do in which situation. However, that was not the goal as this would limit the main goal of clarity of different parts and participants for the whole process.
Basically the Issue Dispatcher should check and provide labels based on which the other roles should take actions. For sure just a label is not enough and additional request/questions should be also added by him/her.
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