Release Engineering

We regularly do QA and bughunting. This includes:

• stress testing LibreOffice development builds and pre-releases (alpha, beta, RCs) on multiple platforms, x86 and x64 architecture, including Android viewer, Android Remote and iOS Remote
• confirming bugs and fixes, with bibisecting when necessary
• triaging unconfirmed bugs on master
• running test builds/daily builds/snapshots (“master”) to try to find regressions early in release cycles
• keeping a continuous overview and reporting on the state and progress of LibreOffice QA as seen on its bug trackers, mailing lists, and other communication channels (e.g. IRC)

To make the whole process scale well, keep in mind the following best practice:

1. Prioritizing (do not waste too much time on this)
   1. go through bugs with status NEW in reverse chronological order (to catch recently reported issues first)
   2. quickly skim title and comments (give a cursory glance!)
   3. then decide on the priority, identifying crashes, data loss etc.
   4. add a quick comment about the change
2. Tagging (without the need to triage fully)
   1. Identify areas where tagging is missing (e.g. regressions need bibisectRequests on them unless it is specifically requested to not have that)
3. Documentation
   1. Updating documentation as needed pertaining to QA related tools and recommended "best practices"
4. Onboarding of volunteers
   1. Regularly reach out to different channels to grow the team
   2. Document what was done, what works, set goals (e.g. number of new volunteers per month)
   3. Use social media, triaging (leaving a comment with an invitation to join), mailing lists (reaching out on other mailing lists)
   4. NB: Recruitment through in person events should be the exception, and we should frequent events where concrete new members are gained more often