Cwa-app-android: What are TODO's mentioned in the documentation?

[corneliusroemer]

I've seen references to "TODO's" in the documentation, however, I have no idea what you mean by a "TODO", of course I know the concept of a todo list, but where is this mysterious list?Please explain here and if possible clarify in the documentation.

This is a place where "TODO's" are referenced:

In General every TODO can be regarded as an issue. You are free to tackle the TODO's anytime!
https://github.com/corona-warn-app/cwa-app-android/blob/master/README.md

[pr1metine]

If you use IntelliJ IDEA you will be able to access the "TODO tool window".

[DE-Max-42]

As well in Android Studio.

[djwessel]

Normally writing "TODO" in comments/documentation helps developers mark areas where more work needs to be done or some issue needs to be addressed. So if you see a TODO in documentation or in the source code, it is because whoever wrote the TODO thinks that something needs to be addressed/done. TODO comes from the concept of "to-do lists".

[marcmuschko]

@djwessel thank you for the explanation :)!
@corneliusroemer thanks for pointing it out. However, this will not be added to the documentation, as we currently do not plan to include explanations for commonly used development practices.

Thanks for understanding!
Best,
Marc

[corneliusroemer]

Right, thanks for clarifying these are pointers in the source code, not the documentation/issues.

I apologise for raising a potentially trivial issue.

I noticed that you make many PRs and commits simply mentioning "TODOs" rather than giving a explanatory commit message, maybe this is something you may want to change.

What's the reason for not making the small change suggested by @ironjan? It reduces potential for misunderstandings and doesn't make it less readable.

[ironjan]

@corneliusroemer The changes have been merged in #661 (into dev). I closed #665 myself because it was a duplicate. The updated README is not yet visible because they have not been merged into master which currently the so-called default branch. The default branch's content is shown when navigating to https://github.com/corona-warn-app/cwa-app-android/. To see that my change has been applied, the dev branch must be selected. See also my suggestion in #664 to change the default branch ;)

[corneliusroemer]

@ironjan Thanks for the clarification.
Do you know why changes to github config/readmes etc are not immediately merged into master? These commits don't break anything, there's no need to "test" them.

[pr1metine]

See #539. A reason might be that SonarCube is used for the master branch. It doesn't work with PRs from forks. I tried doing just that with #655 and it resulted in an error.

Therefore, the maintainers disabled SonarCube for the dev branch so that the community is allowed to commit to this repo. Thus, the only way to commit anything as a community member is to make PRs to the dev branch.

[ironjan]

@corneliusroemer It's essentially a matter of workflows. Changes branch off dev, get rebased and merged into dev (dev has a linear history). Once in a while, releases come along and the changes get merged into master. Changes flow "somewhere" -> dev -> master.

An exception for non-code changes may be useful but has the disadvantage that it "breaks the work flow". Also, the changes need to be merged from master into dev, breaking the flow mentioned in the beginning. Suddenly changes swim against the stream; "somewhere" -> master -> dev -> master (the last step is the following release^^).

---

Technical stuff:

Based on the recent git history, best viewed with a visual git client outside github, I assume that the maintainers switched from a non-linear history (branch off master, merge into master whenever) to a semi-linear history with a release branch. The switch took place around 2020-06-10. See the below extracts from the history.