 So this is not going to be an amazingly revealing talk, but just going to share something that I've been doing lately when I've been making fixes and a few extra steps that I've been doing in order to try to avoid regressions. I'm not actually presenting it, am I? Alright, so Cisco's always been really good at running his office interoperability suite and finding problems, regressions with bugs that I've had. So most of the time before it hits stable they get fixed. It would be really nice if my name was not immortalized in a bugzilla with a regression flag on it, so I'm trying to find better ways to do it. So the standard thing of course is to research a problem, to write your patch and make sure that make check runs and it finds no errors and then you can try to patch it. But certainly there should be something more that we can do. So in the example that I'm going to use today, at the top we have Microsoft Office and you see a cell with no space on the bottom, but in LibreOffice there's a space extra on the bottom. So one of the things you can do in Microsoft Format is a conditional style or conditional formatting for upper and lower space. So if you're having multiple paragraphs with the same style then it will not put the space in between, but when you switch styles then the space will go there. So obviously in this case Microsoft is considering that the same style is being used or something like that. In LibreOffice of course this is the last paragraph so you would expect the space to be there, but in Microsoft it isn't. And so the theory then was at the bottom of a cell you just don't put in that conditional space. And it passed all the make checks and it passed all the unit tests that we had attached to the bug report and so is that enough? But we don't want to just fix the document we actually want to fix the problem. And so what I did is I added some debug output to it and then I asserted to find any examples in our existing unit tests that would have been changed. So we're saying don't add any space but where are we actually adding space? And then I ran a make check and so of course that's going through all of the existing unit tests that have been piling up over the years looking for other documents that have the exact same situation that I'm trying to fix. So this is what I did is just put in a debug statement so that I can see as I'm running through these unit tests what's failing, the difference in the value. And this is the part that was being added if it's a .x file and there was some space on the bottom then just do nothing. Instead of adding the space do nothing instead that matched ours. So now instead of doing nothing I'm asserting the fact that I actually had a value there. I don't care if the space was zero already because zero plus zero is zero so I don't care about that situation. I only care about the situation where I would have added a space below before but now I'm adding nothing. So I get some debug output, I assert and then running a make check will fail on one of the unit tests that match or that I'm going to be affecting. And one of them from writer test number seven matched my condition and you can see on this cell here that actually there is space on rows two and three on the bottom. So our theory that we shouldn't add any space at all ever was wrong. It was incomplete. And so that led us to do a little more research into the problem, create some of our own documents and this is what we came up with. So we're using two different styles here and they're configured identically. On one side we start with one style and then end up with the normal style. On the other side we start with the normal style and end with our handmade one. Since they're identical configured you would expect them to look the same but they look completely different. So obviously there's something else at play here and it turns out there's a special rule for using the default, the so-called default style. If you create any other style works one way but the default style works the other way. So what are some of the lessons that I've learned using this approach? Always verify that your certs work on the example that you have. At least for me I easily get my logic wrong and I run this great big long make check and it passes everything. Then I go what? No test at all and I try it on my own test and it doesn't work so I got it wrong. Also adding debug output before the assert lets you identify whether this is likely going to be a useful example to look at or not. Again if you go through and there's no matching examples you probably have the assert wrong. There's lots of documents in QA most of the time when I'm doing this process I'm finding documents that help me out. If there's too many examples so basically everyone try to assert only on the more interesting or highly visible ones. So don't worry about a space of 10, worry about a space of 100 or more, something like that. Assert only on larger values that are visibly more significant. You might be able to find an example that nicely exhibits what you're trying to fix and you can use that as your unit test and avoid another load save operation by using an existing test. Another lesson learned is just to delete the unit tests that you find and then run the assert again. That way you can make sure that you find all of the same, if there's multiple in the same test you can find them all. And when you find one in a certain compartment like DocX format for example then just run each one of the checks in series. One after the other instead of running the whole make check again. Just make sure you go through that one component find all the bugs in it and then run your make check again. Because obviously make check takes a long time. And then finally upload the patch with the assert and the deleted unit tests as a work in progress. So upload that onto Garrett as a form of documentation. So if you upload it as a percent work in process then our build won't try to build it with all your debug stuff in it. It will simply be uploaded and left there for documentations. And also make sure that you put a reply in the comment indicating that you're... I mean it's just a patch site you'll quickly lose it in... You won't find it back if you put some documentation in it. So that is the end of my speech. And if I have time a little minute or two left then I can just show an example of me using it. Okay so here is an example in Garrett where I have an entry here. So the previous patch sets contain debugging information. And so if I go to one of the earlier patch sets and then I can see the... I have documentation of which bugs matched my condition. So if I ever have a regression I can go back and find some other examples of... And other documents that I worked on. Any questions? Any feedback? Like I said it's not an amazing observation but hopefully it will encourage you to focus a little more on avoiding regressions. And it does take time. I usually just at the end of the day I just run and make check when we're having supper or something like that. And let it run then because obviously it takes time. But I find it worthwhile. That's it. Thank you.