LibreOffice 6.0: Exploring the QA statistics
By Xisco Faulí, Quality Assurance (QA) engineer
LibreOffice 6.0 was released on January 31 and this is what happened during its development in LibreOffice’s Bugzilla, which started when the 5.4 branch was branched off from master on May 18 2017.
Note: This blog post has been created based on bugs in Bugzilla that have the whiteboard ‘target:6.0.0’, which means a commit for that bug is included in the release. Other commits referring to other bug trackers (ofz, coverity, rhbz, bnc, etc…) are not covered here, as well as others commits not having a reference to our bug tracker (ie refactoring commits).
In LibreOffice 6.0, a total number of 926 bugs and 88 enhancements were worked on, of which 747 were reported during 2017 (73%), and 267 (27%) between October 2010 and December 2016. July 2017 and August 2017 were the months with more reports, 104 and 108 respectively.
284 reports are related to Writer, 175 to Calc, 134 to LibreOffice in general and 112 to Impress.
This is all thanks to 382 users who reported them.
-
TOP 10 Reporters
Xisco Faulí ( 74 )
Yousuf Philips (jay) ( 69 )
Telesto ( 59 )
Tamás Zolnai ( 44 )
Aron Budea ( 38 )
Gabor Kelemen ( 26 )
Regina Henschel ( 23 )
Samuel Mehrbrodt (CIB) ( 22 )
Mike Kaganski ( 18 )
Olivier Hallot ( 17 )
Once a report has been created in Bugzilla, a third person needs to jump in, triage and confirm it in order to set it to NEW. This is a very important step as it helps the QA Team to deal with the hundreds of bug reports we receive every week.
Doing it in a short period of time after the bugs are reported guarantees those with more priority get fixed more quickly.
67% of the reports were confirmed within the first day, 84% within the first week and 93% within the first month.
Comparing when the reports were created and when they were confirmed gives a similar chart.
This is all thanks to 113 users who confirmed them.
-
Top 10 Confirmers
Xisco Faulí ( 225 )
Buovjaga ( 92 )
Yousuf Philips (jay) ( 48 )
Aron Budea ( 42 )
Julien Nabet ( 38 )
raal ( 37 )
Tamás Zolnai ( 28 )
Heiko Tietze ( 28 )
Alex Thurgood ( 25 )
V Stuart Foote ( 23 )
Finally, once the reports have been confirmed and triaged, the developers need to investigate and fix them. Sometimes, it can be trivial fix that takes a few minutes to get fixed – sometimes it takes several man days.
10% of the reports got fixed within one day, 51% within one month and 80% within one year.
Taking a closer look at the period between 2017-05-18 and the final release, 111 bugs were fixed in average a month, being August 2017, September 2017 and October 2017 the highest, with 147, 147 and 139 reports fixed respectively.
This is all thanks to 100 developers who fixed them.
-
Top 10 fixers
Caolán McNamara ( 105 )
Tamás Zolnai ( 57 )
Julien Nabet ( 48 )
Eike Rathke ( 46 )
Miklos Vajna ( 43 )
Michael Stahl ( 41 )
Adolfo Jayme ( 41 )
Yousuf Philips (jay) ( 39 )
Justin L ( 31 )
Heiko Tietze ( 28 )
For more QA statistics, please watch my recent talk at FOSDEM 2018:
https://fosdem.org/2018/schedule/event/ode_overview/
Join in, and help our QA community to polish future LibreOffice releases! We’re a friendly and growing project, and there are many ways to get involved: https://wiki.documentfoundation.org/QA/GetInvolved
Its nice to see all these stats, but it would be really great to have some deeper analysis. Are we finding bugs quickly enough (can you measure the time from regressions entering the code, to being found)? Do beta releases or bug hunting sessions help find bugs (is there a surge of bug finding)? If so should there be more? should they be closer or further from release? Can we see the benefit of the test suite, bibisect, other tools? Is the situation better or worse than a year ago? Are some areas of the code better than others? Are bug bounties having an effect?
Hi Sam,
thanks for your comment!
Right now I can answer some of your questions, others, like the one about the time between a regression introduced in the code and being found, would need some scripting with git and Bugzilla.
As this query shows, https://bugs.documentfoundation.org/buglist.cgi?list_id=778281&query_format=advanced&version=6.0.0.0.beta1&version=6.0.0.0.beta2&version=6.0.0.1%20rc&version=6.0.0.2%20rc, 177 bugs were reported against 6.0 beta1, beta2, RC1 and RC2, so I do believe beta releases help. However, I don’t think having more would improve the situation, the release schedule is already tight enough right now.
With regards to the BHS, I think they’re good for 2 things: 1. Engage end users to get involved in QA. 2. Let everybody know a new pre-release is available and ready for testing ( they’re normally organized right after alpha1 or beta1 release )
Regarding the tools we use, in these slides https://conference.libreoffice.org/assets/Conference/Rome/Slides/QA-1YearInNumbers-XiscoFauli.pdf there are some numbers for regression, bisected and haveBacktrace bugs ( page 21 to 25 ) showing that bisecting a bug or providing a backtrace make the chances of getting it fixed higher.
Right now, I can’t tell about the situation compared to last year. Probably I can check what happened in 5.4.0 and see if it has improved or not.
Regards
Hi Sam,
thanks for your comment!
Right now I can answer some of your questions, others, like the one about the time between a regression introduced in the code and being found, would need some scripting with git and Bugzilla.
As this query shows, https://bugs.documentfoundation.org/buglist.cgi?list_id=778281&query_format=advanced&version=6.0.0.0.beta1&version=6.0.0.0.beta2&version=6.0.0.1%20rc&version=6.0.0.2%20rc, 177 bugs were reported against 6.0 beta1, beta2, RC1 and RC2, so I do believe beta releases help. However, I don’t think having more would improve the situation, the release schedule is already tight enough right now.
With regards to the BHS, I think they’re good for 2 things: 1. Engage end users to get involved in QA. 2. Let everybody know a new pre-release is available and ready for testing ( they’re normally organized right after alpha1 or beta1 release )
Regarding the tools we use, in these slides https://conference.libreoffice.org/assets/Conference/Rome/Slides/QA-1YearInNumbers-XiscoFauli.pdf there are some numbers for regression, bisected and haveBacktrace bugs ( page 21 to 25 ) showing that bisecting a bug or providing a backtrace make the chances of getting it fixed higher.
Right now, I can’t tell about the situation compared to last year. Probably I can check what happened in 5.4.0 and see if it has improved or not.
Regards