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

Reply via email to