In response to Bastián and Charles:
To Bastián: It isn't clear whether "author" in your reply "whimsical
and
uninformed comments from the author" referred to the author of the PC
Magazine (and this is certainly a Windows-centric publication) article
or
the author of the posting (me), but no matter. I hope I'm whimsical,
although both Mr. Mendelson (whom I've never met, by the way) and I
have
been using word processors since pre-DOS days. I've been reading his
reviews
and other articles since the mid-eighties. We may both be "wrong" but I
don't really believe either of us is uninformed.
I should point out, however, that your listing of "some articles with
facts
showing quality and low error" all discuss 'code quality' as opposed to
'application quality' - often related, but not at all the same thing.
To
provide a simple example, suppose that someone writes a snippet of code
to
add two integers together: we can consider at least three outcomes when
reviewing this code:
1) The code provides wrong answers, and has a significant memory leak;
2) The code provides correct answers, but has a significant memory
leak;
3) The code provides correct answers and any memory leaks have been
corrected or never existed.
Providing the correct answer would be a measure of 'application
quality',
while avoiding memory leaks would be a measure of 'code quality.'
The articles you reference deal (in my silly example) only with the
question
of code quality (the memory leak). And, yes, it is generally
acknowledged by
everyone that the TDF team has made enormous strides in this regard.
But
this is only tangentially related to 'application quality' (which also
includes a variety of things like "usability," "documentation,"
"interoperability" and a host of other factors.
Another thing to consider is somewhat more intangible, and descends
into
what might be closer to opinion than measurement: since any reviewer
would
suspect that the code described above is redundant (one would assume
that a
library call to add two integers is available), the application in
which my
mythical code exists might well be architecturally deficient. That may
or
may not be a flaw depending on your opinion, but such things, e.g.
unnecessary redundancy, certainly don't promote quality.
But, although (as I said) I don't agree with Mr. Mendelson's
characterization (that LibreOffice is unstable), it seems to me he is
discussing the "correct answer" portion of the code example I give -
which
is appropriate for his audience, most of whom wouldn't have the
foggiest
idea what a memory leak was and wouldn't notice the effects of such a
thing
until the inevitable crash. And, for many users, connecting the crash
to a
specific memory leak might never happen. In fact, the articles you
reference
point to the reasons why the software is more stable now than when TDF
began
attacking it. As you say, there is "still much more to do" but I have
to
think that the steps taken so far are/were exactly the right way to
begin.
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.