Tribler Software Development Process

For everybody involved in developing Tribler, this page documents the process to be followed.

Design

Please design your extensions upfront and don't just go on a hacking spree. You are invited to write down your ideas in a TriblerDesignNote and discuss them with the staff programmers of Tribler, Arno, Boudewijn and Richard.

Coding Standard

To keep things clean there is the TriblerCodingStandard.

Bug Reporting

For bug reporting you must use the ​Tribler forums such that all bugs and discussion are publicly visible. If the issue is security sensitive, contact Arno directly.

Subversion

All Tribler code is kept in the Tribler ​Subversion repository at ​https://svn.tribler.org/. It is also accessible for browsing via the "Browse Source" option of this site. It is structured as follows 

abc/

brokers/

bt2-design/

ffmpeg/

m2crypto/

orchard/

pawel_soft/

publications/

khashmir/
  • 'source:/abc' contains the main Tribler code.
  • 'source:/bt2-design' contains the design documents for all our extensions.
  • 'source:/ffmpeg' is our modified version of the ​FFmpeg video-coding library used in TriblerStreaming.
  • 'source:/m2crypto' is our modified version of the ​M2Crypto library that adds support for Elliptic Curve Cryptography. These modifications to M2Crypto have gone into the official M2Crypto code (version 0.16), so this code is not used anymore.
  • 'source:/orchard' is the application-level multicast level for TriblerStreaming
  • 'source:/pawel_soft' is the realm of Pawel G.
  • 'source:/publications' contains the sources for our official papers.
  • 'source:/khashmir' contains our modified version of the mainline DHT to be used with Tribler.

Following the Subversion common practice the main directories are further subdivided following a standard layout: 

abc/trunk/

abc/branches/

abc/tags/
  • 'source:/abc/trunk' contains the so-called main trunk of ABC. Yes, ABC, not Tribler. Tribler started as an extension to ABC rather than the autonomous fork it is now. For that reason we imported the original ABC sources onto the main trunk and create a main branch on which we would add our code. The plan was to upload ABC's new versions onto the main trunk and we would then take the diff between the old and the new and import these changes to the main branch.
  • 'source:/abc/branches' contains all branches of Tribler. The most important one is source:/abc/branches/mainbranch, the main branch of Tribler on which all development takes place. In addition, there will be 'release' branches on which we stabilize a specific release, as discussed in a moment.
  • 'source:/abc/tags' contains all official Tribler tags. A tag denotes a specific version of Tribler, frozen in time forever. So code in abc/tags is never changed.

Branching Practice

On the main branch the staff programmers of Tribler do major work on Tribler. Once the major work is good enough to become a new release, we create a branch in source:/abc/branches, e.g. source:/abc/branches/release-4.1. On this branch the release is stabilized. New developments for the next major release (e.g. 4.2) can then start on the mainbranch again, independent from the stabilizing of 4.1. Once the release is stable we create a tag in source:/abc/tags, e.g. source:/abc/tags/tribler-4.1.0rc1. We do this for every version we publish, either internally or externally, such that we always have the original source code when someone reports a bug. When the internally published release candidates have proven stable enough for public release, we create the final tag source:/abc/tags/tribler-4.1.0 and release. The release-X.Y branch will continue to act as bug-fixes branch, in which the staff programmers fix the minor bugs that popup after the code has been released. The bug fixes and main branch are off limits to students, sorry.

This scheme is the scheme suggested in the ​Subversion book, Chapter 4: Branching, Section: Common Use-Cases / ​Common Branching Patterns. In addition to these standard branches there should be "feature" branches where people would work on radical changes, e.g. like Jelle now worked on the new GUI. These branches should be created in you own part of Subversion. When doing major work on a shared branch, please create a feature branch.

My Subversion

You are welcome to create your own tags and branches, as long as you stick to the following procedure:

  1. You should create a separate subdirectory for your stuff: e.g. source:/abc/branches/arno, source:/abc/tags/arno
  1. In that subdir, you can do whatever you want, but it is recommended to name your branches following this scheme:

dYY-MM-DD-xxxx-from-BRANCHNAME-rREVISION

e.g.

d06-08-14-socnet-from-mainbranch-r1537

So YY is a 2-digit year, MM a 2-digit month, DD a 2-digit day, BRANCHNAME is the name of the branch you are branching off from, and REVISION is the revision of the repository at the time of the branch. The BRANCHNAME and REVISION information are very important to be able to track your changes from the original to your version later. The staff programmers need this information to import your work onto the main branch when the time comes.

User Interface

Selection of RAD tool for Tribler interface. Pro & Con for each tool in our case where 'Skinnable' is important is available at: ​http://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features. Our preference is currently on the VisualWx software.

Versioning

We use three level versioning (x.y.z). One of the reasons for 3 level versioning is psychology. Many people will assume V5.4 is more compatible with V5 than V9 even though there are both 4 possible version numbers in between in both cases. In general, compatibility between versions should be specified explicitly. 3-level versioning also allows parallel public releases of different branches of development (e.g., bugfixes for stable version 5, new releases for bleeding edge V6).

Any new public (=noninternal) release of an interface or implementation should increase at least one component of the version. In some cases we will be working towards a specific version, e.g. now we are working towards V4 of Tribler. In such cases, for internal releases we postfix the version with rc (release candidate) and a number. Whenever someone releases a new internal version this is accompanied with an rc specification, and the number is always increases. The idea behind is that you always know about which version we're talking, in meetings and mails. Using dates rather than rc numbers is not ideal, as sometimes multiple candidates are released per day. When we are satisfied the software can be released to the public, the rcX is dropped.

Building Releases