<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Temporarily huge memory usage bump when saving a copy of a file (containing HI-res images); release is delayed" href="https://bugs.documentfoundation.org/show_bug.cgi?id=118603#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Temporarily huge memory usage bump when saving a copy of a file (containing HI-res images); release is delayed" href="https://bugs.documentfoundation.org/show_bug.cgi?id=118603">bug 118603</a> from <a class="email" href="mailto:todventtu@suomi24.fi" title="Buovjaga <todventtu@suomi24.fi>"> Buovjaga</a> <pre>(In reply to Telesto from <a href="show_bug.cgi?id=118603#c4">comment #4</a>) > @Buovjaga > Slightly off topic, but I still get confused by the term 'regression'. The > QA has a user perspective and DEV's have a technical approach. Which isn't > to helpful, in my opinion. Not sure if there is need for some clarification > (or more confusing keywords) > > My own list of sub-types: > a. A regression between versions of LibreOffice (the behavior changed to the > worse, sec). Uninterested in how and why > b. Regression which happen outside the LibO code, due a change in the > operation system (the code has not changed, isn't working anymore as > expected) > c. Technical approach: unexpected /unintended side-effect of a code change. > Which includes a, maybe b but not c > sub a. something that the DEV broke with his commit (in strict sense) > sub b. something that the DEV broke, because of brokenness down te road > because of a different code path > sub c. something that the DEV already expected to happen; (for example: > harmonising font rendering made latin font handling a lot slower) I'm not seeing the split in perspective. The user perspective might initially be hazy because of lack of understanding, but surely we arrive to a common perspective after discussion and investigation? If a so-called regression is a change in behaviour that was pushed by the design team, then the users just need to accept it. If there is an argument over changing use of systems resources (such as more mem use and less CPU), I think users without insights into specifics should stay out of the discussion. There is no use arguing, if one does not understand the reasoning behind a change and is not able to propose an alternate solution. This does not mean that testers should skip altogether investigating alarming things they observe. Your example "harmonising font rendering made latin font handling a lot slower" is still a regression, but it requires a completely new approach as a component was changed wholesale. It is thus a lot less trivial than the usual regressions caused by a mistake or some unforeseen side-effect. I don't see how your case b. has a relation to LibreOffice devs, or maybe you meant "the DEV of operating system X broke something". We have to work around OS bugs or change features accordingly, yes, but these cases cannot be called our regressions, because there is nothing to bisect.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>