Second Bug Hunting Session for LibreOffice 5.4

LibreOffice 5.4 will be announced at the end of July 2017, with a large number of new features which are summarized on the release notes page: https://wiki.documentfoundation.org/ReleaseNotes/5.4. In order to find, report and triage bugs, the QA team is organizing the second bug hunting session on Friday, June 09, 2017. Tests will be performed on the second Beta version of LibreOffice 5.4, which will be available on the pre-releases server (http://dev-builds.libreoffice.org/pre-releases/) a few days before the event. Builds will be available for Linux (DEB and RPM), MacOS and Windows, and will run in parallel with the production version.

Mentors will be available on June 09, 2017, from 8AM UTC to 10PM UTC on FreeNode #libreoffice-qa channel (connect via web chat). Of course, hunting bugs will be possible also on other days, as the builds of this particular Beta release (LibreOffice 5.4.0 Beta2) will be available until the third week of June.

During the day there will be two dedicated sessions: the first to chase bugs on the main LibreOffice modules between 3PM UTC and 5PM UTC, and the second to test a set of the top 7 features between 5PM UTC and 7PM UTC. All details of the second bug hunting session are available on the specific wiki page.

During the dedicated sessions, we will concentrate all efforts to chase and reproduce the bugs, in order to confirm and file them in a more comprehensive way. Of course, the more comprehensive will be the bug report, the easier will be for the developers to solve the bugs in time for the final release.

Besides, there will also be manual tests to be executed in TestLink, our new platform for manual tests. More information about TestLink here.

As a new feature this time, we will reward every participant who reports a bug found [*] in LibreOffice 5.4 Beta2 with a shiny ‘Proud Contributor’ sticker:

[*] In order to claim the sticker the bug needs to be reproducible in LibreOffice 5.4 Beta2 and it needs to be a not-yet-reported regression introduced in LibreOffice 5.4, a crash or a bug in a new feature introduced in LibreOffice 5.4. The bug’s description must have the detailed steps to reproduce the problem and the affected document if needed.

Month of LibreOffice, May 2017: The results!

So the Month of LibreOffice, May 2017 has come to a close. We’ve had awesome contributions all across the project, from code patches and bug report confirmations, through to translations and user support. Here’s how many stickers have been awarded:

Click the number for the full details. And then, if you see your name (or username) on that page, claim your sticker! Yes, you can get a cool sticker for your laptop or other devices. Simply email mike.saunders@documentfoundation.org with your name (or username) from the wiki page, along with your postal address, and we’ll send you a sticker in the next couple of weeks. It’ll look like this:

(Note that your postal address will only be used for posting the sticker to you, and not be stored afterwards or used otherwise.) Enjoy showing off your sticker, and thanks again for your contribution!

Behind the scenes

Meanwhile, let’s reflect on the past month. This graph shows how the number of awarded stickers grew over the 31 days of May:

While there was a big jump at the start as new names were added, it was good to see a steady stream of additional LibreOffice contributors over the month. There were no really “quiet” periods – we were monitoring code patches, bug report confirmations, translations, documentation contributions and user support (on Ask LibreOffice), and every day we added new people to the stickers list. This reflects on a healthy and lively project and community, so long may it continue!

And a final word: when you look at the “Contributing code patches” section of the stickers page, note that these are community contributions, on top of the daily work done by paid LibreOffice developers. It’s great to see so many people getting involved, exploring the source code and working on Easy Hacks.

We’ll be running another Month of LibreOffice later in the year – but you can get involved at any time. Join our friendly community, help make LibreOffice even better, and we look forward to your contributions!

LibreOffice Quality Assurance: six months in statistics (part 1)

During the last six months (from 23 November 2016 to 21 May 2017), many things have happened in LibreOffice and in Bugzilla, its bug tracker, where bugs are reported by users, triaged by the quality assurance (QA) team and finally handled by developers, if needed.

New bugs

During this time, 3664 bugs were reported by 1621 users, of which 425 are tagged as enhancement requests.

Top 15 reporters:

  1. Telesto (285)
  2. Yousuf Philips (jay) (103)
  3. Xisco Faulí (97)
  4. Regina Henschel (61)
  5. Thomas Lendo (60)
  6. Áron Budea (51)
  7. Volga (45)
  8. Gábor Kelemen (44)
  9. Samuel Mehrbrodt (42)
  10. Heiko Tietze (31)
  11. andreas_k (28)
  12. Cor Nouws (27)
  13. Miklos Vajna (25)
  14. Mike Kaganski (25)
  15. Timur (23)

The following chart shows the total number of bugs reported each week during this period, week 48 of 2016 being the week with the highest number of bug reports (185) and week 52 with the lowest (94) – and with week 52 being the last week of the year, this comes as no surprise:

Writer (1168) is the component with the most bug reports, followed by Calc (647), LibreOffice in general (495), Impress (284) and the user interface (UI) (253):

Most of these bugs are reported for all operating systems (2194). However, some are specific to Windows (791), Linux (518) or macOS (142). This is an important part of the triage process, as it’s fundamental to determine whether a bug affects all operating systems or just some of them.

The same happens with the CPU architectures. Most of these bugs affect all architectures (2725), while some affect only x64 (790) or x86 (140) computers:

Onto bug statuses: freshly reported bugs start as UNCONFIRMED, and have to be independently confirmed to become NEW. If they can’t be confirmed, the QA team often asks further details from the reporter, and sets the status to NEEDINFO.

Once a bug has been confirmed, a developer can pick it up, and either have the bug ASSIGNED to him or her – or submit a fix and set status to RESOLVED FIXED right away. Once the issue has been fixed, the fix should be (and sometimes is) VERIFIED.

A couple of other statuses could indicate different reasons why the bug report was closed: the bug is not there anymore (RESOLVED WORKSFORME), it was already reported (RESOLVED DUPLICATE) or it was not a bug in the first place (RESOLVED NOTABUG) to name a few.

This is the current status of the reported bugs:

Here we can see that most of them are either set to RESOLVED (1534) or to NEW (1302) which represent 41.8% and 35.5% of the total respectively. 373 are set to NEEDINFO and 257 are still UNCONFIRMED.

In the following chart, we can see that most of the RESOLVED bugs created during the last six months are closed as DUPLICATE (550) or already FIXED (549). 205 are closed as WORKSFORME, and 201 as NOTABUG.

Unconfirmed bugs

Having a low number of unconfirmed bugs allows the QA team to have a quicker feedback loop between users and developers.

On 17 November 2016, the number of unconfirmed bugs was at 562 – and on 11 May 2017 it was at 450, which shows a downward trend over the months:

During this time, 2941 bugs were triaged and moved from UNCONFIRMED to some other status by 174 people.

Top 20 ‘Confirmers’:

  1. Xisco Faulí (727)
  2. Buovjaga (648)
  3. V Stuart Foote (139)
  4. tommy27 (109)
  5. Áron Budea (101)
  6. m.a.riosv (94)
  7. Julien Nabet (84)
  8. Alex Thurgood (83)
  9. Heiko Tietze (81)
  10. Jacques Guilleron (79)
  11. Yousuf Philips (jay) (77)
  12. Telesto (69)
  13. Cor Nouws (40)
  14. Samuel Mehrbrodt (34)
  15. carlos.deambroggio (33)
  16. Regina Henschel (30)
  17. Olivier Hallot (24)
  18. Joel Madero (23)
  19. Miklos Vajna (22)
  20. Adolfo Jayme (22)

You can check the current list of unconfirmed bugs here. More help is always welcome in keeping the project healthy and bug-free!

This concludes the first part of the statistics – we’ll post the second part soon, so keep an eye on the blog.

Video interview: Olivier Hallot, Documentation Coordinator

Olivier is one of the founding members of The Document Foundation, and has been involved in LibreOffice (and OpenOffice.org before that) for many years. Today he works as the Documentation Coordinator for LibreOffice, and in this video he talks about updates to the technology used by the documentation team, as well as the importance of building communities:

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Month of LibreOffice, May 2017: The final week

There’s one more week to go in the Month of LibreOffice for May 2017 – so you still have a chance to get a snazzy printed sticker for your laptop or desktop PC! Here’s how many stickers have been awarded so far:

Click the number to see how the contributions are spread across projects in the community. Want to get a sticker yourself? Read on! Just by helping other users on Ask LibreOffice, or confirming a bug report, you can make LibreOffice better and get one of these…

How to get a sticker

There are many ways you can help the LibreOffice project and claim a sticker:

  • Answer questions from users: Over on Ask LibreOffice there are many users looking for help with the suite. We’re keeping an eye on that site so if you give someone useful advice, you can claim a shiny sticker.
  • Help to confirm bugs: go to our Bugzilla page and look for new bugs. If you can recreate one, add a comment like “CONFIRMED on Windows 10 and LibreOffice 5.3.2”. (Make sure you’re using the latest version of LibreOffice.)
  • Translate the interface: LibreOffice is available in a wide range of languages, but its interface translations need to be kept up-to-date. Or maybe you want to translate the suite to a whole new language? Get involved here.
  • Write documentation: Another way to earn a badge is to help the LibreOffice documentation team. Whether you want to update the online help or add chapters to the handbooks, here’s where to start.
  • Contribute code: The codebase is big, but there are lots of places to get involved with small jobs. See our Developers page on the website and this page on the wiki to get started. Once you’ve submitted a patch, if it gets merged we’ll send you a sticker!
  • Spread the word: Tell everyone about LibreOffice on Twitter! Just say why you love it or what you’re using it for, add the #libreoffice hashtag, and at the end of the month you can claim a sticker. (We have a maximum of 100 stickers for this category, in case the whole internet starts tweeting!)

Don’t miss out! On June 1st we’ll post the results, and then start sending out the stickers…

LibreOffice leverages Google’s OSS-Fuzz to improve quality of office suite

Berlin, May 23, 2017 – For the last five months, The Document Foundation has made use of OSS-Fuzz, Google’s effort to make open source software more secure and stable, to further improve the quality and reliability of LibreOffice’s source code. Developers have used the continuous and automated fuzzing process, which often catches issues just hours after they appear in the upstream code repository, to solve bugs – and potential security issues – before the next binary release.

LibreOffice is the first free office suite in the marketplace to leverage Google’s OSS-Fuzz. The service, which is associated with other source code scanning tools such as Coverity, has been integrated into LibreOffice’s security processes – under Red Hat’s leadership – to significantly improve the quality of the source code.

According to Coverity Scan’s last report, LibreOffice has an industry leading defect density of 0.01 per 1,000 lines of code (based on 6,357,292 lines of code analyzed on May 15, 2017). “We have been using OSS-Fuzz, like we use Coverity, to catch bugs – some of which may turn into security issues – before the release. So far, we have been able to solve all of the 33 bugs identified by OSS-Fuzz well in advance over the date of disclosure”, says Red Hat’s Caolán McNamara, a senior developer and the leader of the security team at LibreOffice.

Additional information about Google OSS-Fuzz is available on the project’s homepage on GitHub – https://github.com/google/oss-fuzz – and on Google Open Source Blog: (1) https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html (announcement), and (2) https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html (results after five months).