On Wed, 2014-02-19 at 17:27 +0100, Bjoern Michaelsen wrote:
On Wed, Feb 19, 2014 at 11:19:53AM -0500, Kohei Yoshida wrote:
Yet, it's the core developers who will likely be called in to answer
"hey my build failed with this python test, tell me what's wrong!!!"
In subsequentcheck? If that should indeed be the case even then, we can make a
separate "make pythoncheck" target.
Now you are the one being academic here. Stick to the topic please,
which is whether or not Python tests should be used to test core
functionality. Nobody is talking about boost here.
I am talking about testing the _product_ here.
And I'm talking about what tools should be used to test what part of the
product. I think you are at one level above us. No wonder we are
talking past each other.
But to answer that question, if we discover a bug in boost, that should
be fixed and tested in the boost project. Not us.
A bug in boost is a bug in LibreOffice. At least on Windows, but for TDF builds
also elsewhere. And a test that finds a bug is still a good test, even if it
wasnt written for that.
Oh, so we volunteer to carry the burden of testing all 3rd party
libraries that we ship with? A worthy goal indeed but is that really
practical?
Kohei
Context
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.