[Libreoffice-bugs] [Bug 118603] Temporarily huge memory usage bump when saving a copy of a file (containing HI-res images); release is delayed

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Thu Jul 19 08:52:26 UTC 2018


https://bugs.documentfoundation.org/show_bug.cgi?id=118603

--- Comment #5 from Buovjaga <todventtu at suomi24.fi> ---
(In reply to Telesto from comment #4)
> @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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180719/e102fe4f/attachment.html>


More information about the Libreoffice-bugs mailing list