New testing branch

[LogicParrot]

So far, there has been at least two incidents of people getting issues thanks to using the "testing" branch:

1. https://forum.cuberite.org/showthread.php?tid=2205
2. https://forum.cuberite.org/showthread.php?tid=2182

This is an indicator of what we all know - the testing branch is too old, and is in fact less stable than master.

I think we should roll out a new testing.

To avoid being stuck in this loop forever, two things must be done:

1. The mistake of keeping "testing" around too long without graduating it into release should not be repeated. Higher priority should be assigned to fixing crashes than introducing features.

2. In Github, not every crash bug should automatically be tagged with the "testing" milestone. Instead, that should be done only after it is confirmed that the bug was not actually introduced in the "master" branch. Tagging all crashes with "important" makes sense though.

[LogicParrot]

In the meanwhile, the testing branch was removed by worktycho.

[worktycho]

Its a temporary measure, until we can get around to working out what to do with all the pre-existing bugs.

[LogicParrot]

I've updated the compile.sh script to automatically pick the master branch in the meanwhile.

[worktycho]

I think we could retry a testing branch, so long as we can get a better criteria for what is an acceptable bug in stable. At the moment, I'm going for anything that would involve a significant core (cWorld, cChunk, cClientHandle, any class over 500 line of implementation) API change or refactor. Alternatively, any bug where we can not come up with a root cause in the month after opening.

---

The idea is that these bugs are caused by pre-existing code, and new code should be easier to fix.

---

Or we could establish a checkpoint commit, and any bugs that are shown to exist prior to that commit are not release blocking.

[sphinxc0re]

I got nothing to add here. Let's go with the first of tychos options