 Dear Librov's conference participants, viewers, colleagues, members of the community. My name is Tim Murgadzha. I am an engineer working in Quality Assurance. I am a long-term Librov's user and the Document Foundation volunteer contributing in Quality Assurance. I am presenting here some Quality Assurance experience for Collabora. There are different paths that help provide Quality Assurance. Some are done by devs, some in TDF, some in partner companies or their partners of use or users. Many paths lead to GERD. Here we are showing some examples of how Collabora and its partners are helping fix bugs in Librov's technology. There are customers of ecosystem partners which may report a problem, an issue to its own partner. Here is an example. Customer reports incompatibility between Collabora Office and Microsoft Office. After some looking into that, the issue is really about opening of rotated text and table from PPTX document, which, after again looking into the history, was fixed in Librov's 5.4 but regressed in 7.3. Collabora fixed that issue in 7.6 and backported it. Small glitch went wrong again, but it was fixed again soon, with more fixes for saving it in PPTX in 7.6. So what happens here is that Librov's does not support natively this issue, but now it supports opening and keeping of that attribute for PPTX document. During the course of solving this issue, some similar bug reports were checked for vertical text and table shape and so on. There is no doubt that different cases are already reported in Baxila, so missing is only to fix them. Another example of when customers of those ecosystem partners reporting the issue is that users were complaining that something is wrong, that all data is lost. It happened during the column width change because it was accepting invalid input and users complained that there is a sheet corruption and all data is lost. It turned out, after an analysis, that wrong inputs were possible even from OpenOffice, but the corruption started from 6.1 and there was no undo to fix it. So it was really annoying if somebody fell into that trap. Collabora reported that to Baxila and the developer fixed it there in LibroOffice. Collabora just had to additionally fix it in online part. Another example is that when users complained that they prepare a document according to their needs, but then when they open it, it again contains the wrong font and all the time like that. It turned out that it's very old ticket with duplicates and the bug was inherited from OpenOffice. Recently Collabora fixed it this year for LibroOffice 24.2 but also reported it to previous versions. Another set of possibilities how to fix bugs and to collaborate really and to work together is when there are clients of customers of ecosystem partners. Like it's another tire here where there is a user who uses in this case Collabora online who sees a bug but reports this to his or hers own support company. Here is an example that it might be like a Zama ticketing system or something else. That company determines that it's not a problem of their own software. It's an external issue in this way it's really an online issue and asks its own support by submitting, let's say, a ticket in OTRS. Then when it comes to Collabora it triages the issue. Let's assume that it's done in some software called Fabricator. And first it determines if it's online or core issue. Of course core here refers to LibroOffice technology. If it's core issue then Collabora may create a ticket in Baxila. For examples like regression or for some larger issues or when a discussion is needed so it doesn't have to. It may contribute, commits directly to Garrett. What happens there is that a rule of thumb of Collabora is to also contribute it back to LibroOffice master. So all the development done then again stays there as open source software already in master. So what happens here? Users see a problem they have. It may be a problem with a file which makes sense and they report it like that. But when it comes to Baxila, Baxila is issue-based not document-based. If there are multiple issues with the same document there should be multiple tickets. Of course after searching for possible duplicates that's really important. So there may be multiple issues in online, in LibroOffice kit, in core, in different LibroOffice versions traveled fixes. Regressions and so on. Sometimes it may happen, as explained before, that the issue is in OpenXML. But the feature is even not supported in LibroOffice. So there might be a solution there with keeping attributes. So let's see some examples of this multi-tire bug reporting. Client says document has issues, we have a problem with it. Then analysis shows three issues. First it fails to open giving some error. Then with some tests it turns out it's regression. And some it's bisected and turned out that there is a fixing commit in 74 which needs backport. Okay, it was nice. Then the next following issue is that out of 117 pages LibroOffice loads only 34. Which is a nasty regression in 74 which was bisected. And soon fixed by a Dev in 747 which is nice for all users of LibroOffice. Then there is a third, there was a third issue like contents of comments are missing after table of contents. Collab reported it. It turned out that it was regression, bisected it and fixed it. So everything was done. So with that and everything else the whole document looked nice. Following examples of the same multi-tire bug reporting is this. User says I cannot work with this kind of Excel spreadsheets. Even though they are small of one megabit size it's extremely slow and unresponsive both during the loading and during the scroll of the page. So with the help of some profiling and frame graph it turns out it has few issues. Some are in online but the biggest ones and the most important ones are in core. Multiple fixes help really make it smooth. And later on in unrelated ticket one checked it turned out that it was fixed. And in this case it wasn't bisected. The right person was called Kaola. And it turned out it is one of his fixes that when XLSX is opened with large number of comments here 40,000 plus comments. It's speed opening time went from 180 seconds to 10 or 20 seconds depending on a machine. So it's really a noticeable performance improvement. Then there is another type of closing bugs and working on bugs. It's not like a simple thing that can be fixed with one commit even with few commits. But it's really large work that requires a lot of commits, a lot of fixes. One of the biggest in this year and is an example of DuckX opening of multi-page floating table that annoyed many users. So originally there were 14 duplicate bug reports. After Miklos fixed some of these he continued and the following set of 50 plus commits covered 14 other previous bug reports and 5 newly found issues. I saw that some tickets were closed as work for me without reverse bivisect so it may be even more. There is a third now part of fixing with 7 commits at the time of recording this presentation. So with all this it seems like the most duplicated set of issue I saw in Bakzilla counted 38 tickets. The biggest number of duplicates according to Bakzilla report I saw the duplicates were 34. And there is that report I think it's updated I think regularly. So this would be very huge, a large chunk of fixes and fixing of long term issue, something annoying users for 10 years. But that really rises here a question. How is open source development done in a bulk? How can a large feature be done? There might be some other ways but the realistic way and the one done here is that it was a feature request, large feature request from customer. There are here also some other ways, different ways of contributing to triage development. For example when someone out of not even working, working or not on the issue, searches and cleans many tickets and makes a lot of duplicates. Here is example of when Mike did it, it's really a number of tickets. Of course I saw also Justin doing it very frequently. And then there is another type, totally another type of development is when while always checking and working on master, you'll see some, the sheer number, the sheer quantity of checking makes you discover different things. Like here a crush on load, it's clover reported with a sample and bisect and they fix it in two days. Or another crush in calc which already was in production in 755, which seemed very stable. But then with the help of sample bisect and a dev, it was fixed the same day and back ported to 756. And there was example of crushings in GTK3. It turned out that it's not a simple thing to do, but very soon in two days it was, it was reverted until the better solution is provided. So I cannot thank enough to all those folks here to do mentioned ones or to Jim or Laszlo or Kaolan working on all this. But there is speaking of the ways how, how TDF attracts developers and other folks to contribute to Bakzila. There is one, there is a special way of like organizing Librocon, Libros conference and inviting people to present there. So while preparing for presentation, just today I either bisected open two bags, closed a test of three, encountered on open two, what can I say, just no animals were harmed during the present, preparing presentation, recording of video. Let me, in two closing slides, just give some overview of Libros Office technology. There are various, of course, products based on Libros technology like online and office from Libros Office or Collabora and apps from Libros Office or Collabora. What's important here is that tech-saving users should always check and see if the bug exists in Libro Office. That's the first step ever. If it exists, fine, then you simply track it or CC yourself or whatever, if not create. Only if it doesn't exist, then the Collabora bugs should be reported at GitHub, so it's second step. There is a small difference with the mobile apps. Collabora apps is different in technology from Libro Office viewer. So Collabora mobile apps should be reported to GitHub and Libro Office viewer bugs to Bakzila. I just wanted to clarify this as I saw, of course, some colleagues from the community not differentiating all those things. And speaking about that, there is a fresh, there are fresh Collabora mobile apps. The previous one was 2111, the current one is 2305, but just recently released in September 2023, so it's really fresh new event. I invite you to test it. After the presentation, maybe I would like to conclude with speaking about the enterprise use of Libro Office. So the classic approach is to use, to have a conservative use of still branch, but for even bigger companies and more serious companies for different reasons. Different other reasons like subscription that would make additional fixes and new development. There are enterprise supported versions of Libro Office, like the Collabora Office, which has backports fixes from fresh branch or master with the support. And with the assessment of which backports can be maybe troubled, so not all is backported. And with that, there is Collabora Office 2205, which is based on Libro Office 73, which has different subversions of how throughout time it changes. Current Collabora Office 2305 is based on Libro Office 75. What's important here to say is that it also gets as a stable version some features from the following version, which at that time 2305 was not stable like 76. Okay, thank you for listening and watching this one. Timur is also my name is Baxila, so I hope you to see you there or see you somewhere else. Thank you and goodbye.