“Eins, zwei, drei, vier, fuenf, sechs, sieben, acht”
So LibreOffice 4.2.0 release candidate 3 has been tagged yesterday evening. A good time to look back at the cycle and look at some numbers. The number of issues fixed in the 4.2 series are in line with our historic trends:
- 1131 bugs fixed for 4.2.0 beta 1 (at 4.1.0 we had 1045 bugs fixed at that point)
- 48 bugs fixed for 4.2.0 beta 2 (at 4.1.0 we had 76 bugs fixed)
- 67 bugs fixed for 4.2.0 release candidate 1 (at 4.1.0 we had 59 bugs fixed)
- 53 bugs fixed for 4.2.0 release candidate 2 (at 4.1.0 we had 86 bugs fixed)
There is no page for the third release candidate yet, but I assume it to be no exception. Fixing issues is mainly done by development, although QA does the preparation for that by triaging a bug well. But QA also does quite a bit of work before a bug is triaged, and this is not directly locked to changes in code. So I had a look at the numbers simply in the timeframe between the tagging of 4.1.0 rc3 (2013-07-17) and 4.2.0 rc3 (yesterday). In this timeframe, QA did:
- confirm 3114 bugs (change of ever_confirmed).
- resolve 3393 bugs (change of resolution and not unresolved now, this includes the bugs fixed by development).
Naturally, these can not be simply be added up: for example, a bug can be confirmed and then be resolved by fixing it. If all of that happens in the timeframe (as it likely will for a relevant bug), it will appear in all the above counts. Meanwhile, in this timeframe 4092 bugs have been filed by endusers. Of those new bugs filed, 9.3% where enhancement requests. Since not all resolved bugs need to be confirmed (e.g. invalid bugs), these numbers add up nicely.
Speaking of quality, another thing to look at is regressions. How many of those will be fixed in 4.2 as of now? Here is the rundown:
- 1 regression introduced in 3.4 or before
- 2 regressions introduced in 3.5 or before
- 3 regressions introduced in 3.6 or before
- 2 regressions introduced in 4.0 or before
- 8 regressions introduced in 4.1 or before
- 51 regressions introduced on master or found in betas and release candidates
As you can see, most of the regressions fixed with this have actually never been released. This should be encouraging news to those testing daily builds: If you do that, you will be rewarded with quick bug fixes. Still, only fixing 16 regressions that were visible in previous releases seems a rather low count for a release. Well, this is because this count does not count fixed regressions that are also backported to the updates on the 4.1 stable series. As regressions are usually worth that effort, this is usually done unless it is to risky a change for that. If you look for regressions that were fixed in 4.2 and also backported to 4.1, you as of now get a count of:
- 230 regressions fixed in 4.2 that were also backported to the 4.1 series
in addition. See this earlier post for more details on how the backporting works and some numbers on it.
Speaking of regressions, we have a pretty unique tool to corner them: bibisect. How well does this work? I keep tracking these in bugzilla for the last months. Currently 176 bugs have been bibisected, with the number of unresolved bibisected bugs staying constant in the 60-70 range. That is encouraging, as it means that for each regression bibisected, a developer fixes a bibisected regression. This happens currently at a rate of ~2 bugs per week, which is not too bad, as such regressions might be quite hard cornercases that without bibisect would be tricky to pin down. However, only ~14% of our unresolved regressions are bibisected as of now. Clearly, we can improve that ratio with more bibisecting and get more regressions fixed even quicker.
Ok, admittedly, this was a boring and dry post on bug numbers. What can I do to lighten you up? Here is catcontent, presented in LibreOffice Draw 4.2 running on Ubuntu trusty with the awesome new libreoffice-style-sifr icon theme:
tl;dr: We are doing well, but could use even more people testing daily builds and do bibisects.