+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: New testing branch (/thread-2215.html)
New testing branch - LogicParrot - 11-20-2015
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.
RE: New testing branch - LogicParrot - 11-21-2015
In the meanwhile, the testing branch was removed by worktycho.
RE: New testing branch - worktycho - 11-21-2015
Its a temporary measure, until we can get around to working out what to do with all the pre-existing bugs.
RE: New testing branch - LogicParrot - 11-22-2015
I've updated the compile.sh script to automatically pick the master branch in the meanwhile.
RE: New testing branch - worktycho - 11-22-2015
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.
RE: New testing branch - sphinxc0re - 12-23-2015
I got nothing to add here. Let's go with the first of tychos options