I think we should define that when the blockers are fixed we are fine for a beta. We an still fix issues there.
I have collected over 20 issues on jira that focusing on crash, memory leaks and other fatal things. Not to speak of our hideous hash tag issue. Maybe we could create a debug build so we can better hunt issues. Maybe we could create comparable extended crash reports. It is easier to learn to collect data then to fix issues. And if we can distribute research work, maybe developers are faster fixing. What do you think? Am 25. Oktober 2019 04:21:13 MESZ schrieb Damjan Jovanovic <dam...@apache.org>: >On Fri, Oct 25, 2019 at 1:00 AM Marcus <marcus.m...@wtnet.de> wrote: > >> Am 24.10.19 um 14:04 schrieb Mechtilde: >> > First we should try to fix the release blocker >> > >> > https://bz.apache.org/ooo/show_bug.cgi?id=125129 >> > https://bz.apache.org/ooo/show_bug.cgi?id=127731 >> > https://bz.apache.org/ooo/show_bug.cgi?id=128094 >> > https://bz.apache.org/ooo/show_bug.cgi?id=127783 >> > https://bz.apache.org/ooo/show_bug.cgi?id=127774 >> > >> > We think Issue 127731 and 128094 have a similar reason. >> >> I also think that we should fix these blockers and check for others, >> before doing a test build for a wider audience. It would increase the >> quality and therefore also the public acceptance. >> >> +1