End manual backporting

[qstokkink]

Tribler has had a release and a development branch for many years now. As per the git flow model fixes are made onto the latest release branch and then also merged into the development branch. This is fine.

However, applying fixes from the release branch to the development branch has to be done manually. This comes at the cost of the sanity of whomever has to actually perform this merge and invariably leads to errors, such as these:
#5090 (comment)
#581 (comment)

To get rids of these types of errors and consequently having to fix the same bug twice we should automate as much as possible:

• GitHub supports webhooks which allow our Jenkins machine to see when a new commit has been pushed to the release branch.
• The jenkins-ci user can then automatically apply this merge in 99% of the cases (I'll get to the other 1% in a bit) and automatically open a PR for this change with the original PR body onto the development branch. By also copying the original PR body and merging into the development branch issues that are marked as "fixed" in the original PR will automatically be closed by GitHub without human intervention (which is also completely manual right now).

In this manner all branches stay up to date and functional, developers can actually develop (and not worry about the process) and we will have less errors.

What about the 1%? So yes, merging does not always succeed from the release branch to the development branch. So our options are then to (a) fire-and-forget and hope someone (who has no in-depth knowledge of what the code does - or forgot by the time he arrives at the scene) fixes it manually for us in a big backport merge at a later date or (b) open the conflicting PR automatically so the one who has made the code has to jump in and fix it.
In light of code ownership and the you break it for everyone, you fix it for everyone mentality of monorepos (see #5386 (comment)) I believe the fully automatic approach is the better one.

[ichorid]

I am perfectly willing to sacrifice my sanity every time I have to merge release into devel. I did it many times, and still have some sanity left. Doing the stuff automatically will result in an ungodly amount of auto-generated merge commits. Also, I don't want any automated system getting write access to the repository.

My solution to the problem of merging stuff would be less technical and more organizational: just start doing releases more often, so there are no big backlogs and merge conflicts are easy to resolve.

[qstokkink]

Also, I don't want any automated system getting write access to the repository.

That won't happen. Such an automated system can create PRs from a fork: it doesn't modify the repository directly. In case you think that's too good to be true: I made this for IPv8 already.

[qstokkink]

Also, regarding --what is maybe the most important-- point:

I am perfectly willing to sacrifice my sanity every time I have to merge release into devel. I did it many times, and still have some sanity left.

I am not fine with you wasting your sanity 😃, or your time for that matter. Anything a machine can do faster and just as well (or better -- see my examples in the original post) should be done by a machine.

[qstokkink]

This workflow has now been adopted.