Can one of the developers define how something is determined to be a regression. My assumption is that if it worked in Alpha 4.1, and does not work in a current nightly, it is considered a regression. Please correct me if I am mistaken.
A second question is whether Haiku has a method implemented to track such regressions.
you can add a bug report in the haiku bug tracker
tutorial how to use: http://besly.de/menu/search/archiv/dev/haiku-trac.html
use translator funktion to translate, because only available in german at the moment
Hi,
Anything that worked in a previous version of Haiku (not only Alpha 4.1, any of the alphas and nightlies) and doesn't work in a more recent one is a regression.
The only way we have to track this is opening a bug report in the bug tracker (http://dev.haiku-os.org). It helps a lot if you can take the time to try to find which revision created the problem. For this you can use the bisection technique described here: https://dev.haiku-os.org/wiki/BinarySearch (either by downloading old nighly builds or compiling yourself from git). This helps a lot, as often when we have a reduced range of revisions the developer can review these more closely and find the cause of the problem.
I suppose we could title such tickets as such, sort of like what has been done with (easy) bug fixes. This way they can be found and targeted using the search function. I have a separate partition on my hard drive for Alpha 4.1, so it is fairly easy to test whether something worked previously when comparing to a current nightly. Are these kind of regression tickets any more important than tickets for new bugs?
I wouldn’t say regression tickets are more important than other bugs, but if the hrev of the regressing change can be pinpointed or at least limited to a small range via the mentioned binary search, the error is easier to spot and fix or the change reverted. So, a “(regression)” in the title seems to be useful, if the accompanying information is more specific than “it used to work 3 years back in alpha4”.
Regards,
Humdinger
I know this is nuts but has anyone even considered porting Haiku to an iPad? Specifically making the older iPad One’s usable again???
You would need to write a script and that script would need to be changed if the development setup changes. It would be great to have an application to download and install Haiku from the night-lies, if the version was within the bisect range. I myself have not built Haiku since about 2008. If I was to try and do this again, it would take me a bit to relearn. I have never done any script writing. I tried to learn some C++ once in early 2010 and was alright until about 4th or 5th lesson in the darkwym series learning to program in C++. I got really bogged down there and gave up. So I sought of doubt my ability with that.
I’m just wondering if binary bisection could be automated or at least partially automated? If the symptoms of a bug could be entered into a program and this program could automatically build or install older versions of Haiku, test for the symptoms. If the symptoms did not occur test another version with an arbitrary number of versions ahead (2 to the power of some number), test again. If symptoms occured, halve the that previous power of 2 and go back that number of revisions and so on back and forth. If it was too difficult to make a program to test bug symptoms, just make a program to build or install different revisions according to the arbitrary 2^# given by the tester. As it might be difficult to test symptoms for some bugs when Haiku completely crashes or freezes. Unless that program could run on another stable version but testing Haiku on another partition or remotely. Anyway it would probably be a great advance just for the person doing the testing even if he/she had to test and watch for the symptoms, as long as the binary bisection, installing or building could be done by the program.
git bisect can do this, it can run a script and check the return code to see if the current version is “good” or “bad”. This involves building the versions from source (instead of using the nightly builds), and someone still need to write the script - not easy as our development setup is quite variable (building from haiku to real partition, building from linux and running in qemu, etc).