Tribler: Brainstorm ticket _The Plan_

[synctext]

(as communicated by @ichorid on 31May 2020) The Plan Having said all that, I propose:

• Short-term:
  
  
  
  • [x] Remove the entirely useless CreditMining subsystem and "Trust Graph" panel from 7.5.
  
  
  • [x] Release 7.5 w/o fixing the "0kb/s" bug (but fixing the remaining usability bugs). Fixed
  
  
  • [ ] Postpone any activity resulting in increasing the codebase size until new team members arrive in September.
  
  
• Mid-term:
  
  
  
  • [ ] This Autumn, focus on DevOps and infrastructure, type annotations, modern Python development process.
  
  
  • [ ] Start doing "early access" builds with enabled "performance watchdog" sending logs automatically to get more users engagement (this will enable us to catch the "0kbs bug" and its kind).
  
  
  • [ ] Move AnyDex into a separate app with a web-based UI.
  
  
  • [ ] Review the necessity of every dependency in our codebase.
  
  
  • [ ] For 7.6, focus on building a working social score system that does not instantly piss off new users by showing them negative balance as our current token system does.
  
  
• Long-term:
  
  
  
  • [ ] Hire outsources to develop a proper UX/GUI.
  
  
  • [ ] For 2021, focus on building a working community-trust-score-based collective seeding system (e.g. people collectively seeding stuff from a subscribed channel).
  
  

[hbiyik]

May be releasing with libtorrent 1.1.x branch is a safe approach for 0kbps bug, I also had some funny connection issues with libtorrent 1.2.x where I can not give concerete details, i just downgraded libtorrent 1.1.x and lived happily.

[ichorid]

@hbiyik , I was considering this option. We figured out the 0kb/s bug was there at least since 7.4. There were no complains (though it does not mean there was no problem). Probably, the complains were triggered by problems with tunnel downloads (which were very real).

[devos50]

Start doing "early access" builds with enabled "performance watchdog" sending logs automatically to get more users engagement (this will enable us to catch the "0kbs bug" and its kind).

For this, I would recommend starting with a basic, separate Tribler debug build on all platforms, and add more advanced debugging features on the go. I think an important first step would be to include a libtorrent version with debug symbols enabled when building the debug version. Other non-invasive, yet useful debugging practices I can think of:

• Add a checkbox to the crash report dialog in the GUI to also send (parts of) the log to us. This requires minor modifications to the error reporter backend, which hasn't been touched in years.
• Send the last CPU/memory statistics to the error reporter.
• More detailed logging of POST request parameters.

[synctext]

Reminder: there are modern frameworks for easy mocking and reducing boilerplate code. Python 3.8, PyMock and Pypi Mock.

We have the unit testing, PR tests, app tester, Gumby testing framework, deployment testing using forum users in the wild.

Ideally we can reproduce even the most extreme nasty bug in a compact way. For instance, triggering the DHT security mechanism by seeding 20 swarms. This is very rare bug, we seemingly contacted a wild peer twice with different swarm hash, thereby triggering the anti-flooding DHT mechanism. This has taken 2 weeks to investigate, not yet reproduced with reliability.

[drew2a]

Hi all!
@ichorid asked me to review the repo, so here I am.

I've done it on a very hi-level, but I hope it would be helpful.

There is no "git flow" model

1. Last commit to the master branch was at 26/03/2019, but we have fresh 7.4 version dated 21/02/2020
2. No base "gitflow" rules, when release branch should be merged to master and develop, etc.
3. Messy naming:
   
   
   
   • devel instead of develop
   
   
   • release-7.3.0 and v7.3.0 (what the differences?)
   
   

Reference

https://nvie.com/posts/a-successful-git-branching-model/

Proposal

Apply all gitflow requirements, or choose another branching model (eg GitHub Flow: https://guides.github.com/introduction/flow/).

No CONTRIBUTING.md

As I know tribler is waiting for a few new members.
If yes, it would be nice to have own "How to Contribute" guidelines.

I've seen https://tribler.readthedocs.io/en/devel/contributing.html but the target is a user, not the developer.

References

• https://github.com/atom/atom/blob/master/CONTRIBUTING.md
• https://github.com/microsoft/vscode/blob/master/CONTRIBUTING.md
• https://github.com/Privatix/dappctrl/blob/master/CONTRIBUTING.md

Proposal

Add CONTRIBUTING.md with all the guidelines for the developers, include codestyle and etc.

Opportunity to add more automatisation

1. Automatisation of a development environment (run single install_dependencies.sh instead of running the several commands): https://tribler.readthedocs.io/en/devel/development/development_on_linux.html
   
   
   
   • It can be used by a developer or by a robot in CI (for example)
   
   
   • Maybe there is a way to use docker
   
   
2. Automatisation for the bug reporting (it is almost always better to have script (or button) rather then "manual instructions"): https://tribler.readthedocs.io/en/devel/contributing.html

No test results and no build results in PR

As I see there is no test results and no build results in Pull Requests.
Example: https://github.com/Tribler/tribler/pull/5390
Therefore there are no proofs, that this PR doesn't broke the build.

Proposal

Add a build result and a test result to each PR.

Appendix

It would be awesome, if developers had a report of packaging status (mac, nix, win).

[ichorid]

@drew2a , thanks for your suggestions. We're currently in transition to a cleaner repository/branching/tagging rules

It is obvious that in its current state Tribler repository is not too friendly for a complete stranger developer who would like to contribute. We should set some clear guidelines.

Regarding the test results, they are there. The PR you referenced just passed all the tests, that's why the results were hidden by GitHub behind a big green friendly button :smile:

[synctext]

@drew2a thnx! PR more extensive test results and performance monitoring are most welcome.

Really fascinating how this works. This is a keyword search with 503 results returned.

For the remainder of the year 2020 I propose to focus on polishing what we have (up for discussion). Then in 2021 we can experiment and try out radical stuff like replace our entire storage layer (e.g. SQLite/PonyORM), replace trustchain, dump VLC or some other radical ideas that might take us to the next level.

[ichorid]

Updated in #5587