Task #3570
openCreate a bugzilla-based community-distributed bibisection mechanism
0%
Description
Bibisecting is a PITA: Large download, difficult to set up, and very few people do it; see also task #3529 .
But many people, I suspect, would be willing to contribute to bibisecting by downloading a single build (preferably, not not necessarily, a portable build not requiring installation), and checking whether the bug manifests with that build.
Now, when a bug needs bibisection, people visiting the bug page could see a suggestion to help with one step of bibisection - along with a download link for a single build: The build that bisects the current known range containing the first manifestation. The next time they visit the bug page - or even in the open browser from which they clicked the download link - they would be asked to report whether or not the bug occurred with the build they downloaded. If they respond, that would have the same effect as marking good/bad during git bibisection. And the next page visitor would then be offered another build.
Naturally this can be made more complex - by offering different builds to multiple visitors, i.e. if one visitor took the 1/2 build, then offer the next two the 1/4 and 3/4 builds etc. Another option is to offer the same user to take multiple builds, e.g. two (which would be at 1/3 and 2/3) or 3 (which would be 1/4, 2/4 and 3/4).
The download links might need to be torrents to minimize bandwidth use.
Updated by Xisco Fauli Tarazona almost 3 years ago
Eyal Rozenberg wrote:
Bibisecting is a PITA: Large download, difficult to set up, and very few people do it; see also task #3529 .
What do you mean by 'difficult to set up' ? once downloaded you can bisect issues right away.
Besides, you can also use the release repository, which contains all the releases from 3.3 up to 7.2.3 (357 builds) and it's 11.11 gbs < https://bibisect.libreoffice.org/linux-64-releases >, which means each build is around 32 mbs
But many people, I suspect, would be willing to contribute to bibisecting by downloading a single build (preferably, not not necessarily, a portable build not requiring installation), and checking whether the bug manifests with that build.
Do you have numbers on the number of people willing to contribute ?
Now, when a bug needs bibisection, people visiting the bug page could see a suggestion to help with one step of bibisection - along with a download link for a single build: The build that bisects the current known range containing the first manifestation. The next time they visit the bug page - or even in the open browser from which they clicked the download link - they would be asked to report whether or not the bug occurred with the build they downloaded. If they respond, that would have the same effect as marking good/bad during git bibisection. And the next page visitor would then be offered another build.
Naturally this can be made more complex - by offering different builds to multiple visitors, i.e. if one visitor took the 1/2 build, then offer the next two the 1/4 and 3/4 builds etc. Another option is to offer the same user to take multiple builds, e.g. two (which would be at 1/3 and 2/3) or 3 (which would be 1/4, 2/4 and 3/4).
The download links might need to be torrents to minimize bandwidth use.
Let's say we offer in Bugzilla a random version from https://downloadarchive.documentfoundation.org/libreoffice/old/ so people can download it, install it, test the issue and give feedback. Each time we offer it to a user, they would have to download ~200 to ~300 mbs. This also means they would have to wait until the download and the installation are completed. How is it going to improve the situation to using the release repository mentioned above? To me it looks like they would have to download more data and wait longer than if they just used the bisect repository