I'm sorry to have ignited a discussion for which I wasn't looking. I
clearly don't have the authority to weigh in given my (lack of)
meritocratic wealth in the LibO community, so let me keep this simple:
I'm truly just trying to find an agreeable avenue for hacking on LibO
given my use cases
On 02/19/2014 12:02 PM, Stephan Bergmann wrote:
So, what can we do here? How about an additional code module dedicated
to subsequentchecks written in Python, which, while serving the useful
purpose of testing specific application functionality (and in which role
they may deliberately duplicate
At 6:09am -0500 Thu, 20 Feb 2014, Stephan Bergmann wrote:
On 02/19/2014 12:02 PM, Stephan Bergmann wrote:
The idea would be that Kevin (and others) would fill this with PyUNO
coding scenarios that cross their mind, discover errors in the PyUNO
infrastructure, ideally distill tests for those
[putting the dev list on CC, quoting the original mail in full below for
reference]
Hi Kevin,
First of all: great that you want to improve the PyUNO situation! This
is a part of the code that could indeed benefit from lots of love.
Regarding the Python tests, I see both sides' points:
On
Hi,
On Wed, Feb 19, 2014 at 12:02:35PM +0100, Stephan Bergmann wrote:
The idea would be that Kevin (and others) would fill this with PyUNO
coding scenarios that cross their mind, discover errors in the PyUNO
infrastructure, ideally distill tests for those specific errors out
of the more
On Wed, 2014-02-19 at 12:32 +0100, Bjoern Michaelsen wrote:
Hi,
On Wed, Feb 19, 2014 at 12:02:35PM +0100, Stephan Bergmann wrote:
The idea would be that Kevin (and others) would fill this with PyUNO
coding scenarios that cross their mind, discover errors in the PyUNO
infrastructure,
On Wed, 2014-02-19 at 12:02 +0100, Stephan Bergmann wrote:
So, what can we do here? How about an additional code module
dedicated
to subsequentchecks written in Python, which, while serving the
useful
purpose of testing specific application functionality (and in which
role
they may
Hi,
On Wed, Feb 19, 2014 at 09:29:36AM -0500, Kohei Yoshida wrote:
Telling core developers who diligently maintain C++ tests to maintain Python
tests just because someone likes to write them (but not maintain them) is
equally silly.
Nobody told core developers to do so.
And you are asking
On Wed, 2014-02-19 at 16:51 +0100, Bjoern Michaelsen wrote:
Hi,
On Wed, Feb 19, 2014 at 09:29:36AM -0500, Kohei Yoshida wrote:
Telling core developers who diligently maintain C++ tests to maintain Python
tests just because someone likes to write them (but not maintain them) is
equally
On Wed, Feb 19, 2014 at 4:51 PM, Bjoern Michaelsen
bjoern.michael...@canonical.com wrote:
Hi,
On Wed, Feb 19, 2014 at 09:29:36AM -0500, Kohei Yoshida wrote:
Telling core developers who diligently maintain C++ tests to maintain
Python
tests just because someone likes to write them (but
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
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
I have been doing a ton of work with pyuno at work and am interested in
anything to improve the code quality there.
mike
On Wed, Feb 19, 2014 at 5:02 AM, Stephan Bergmann sberg...@redhat.comwrote:
[putting the dev list on CC, quoting the original mail in full below for
reference]
Hi Kevin,
On Wed, Feb 19, 2014 at 05:20:19PM +0100, Markus Mohrhard wrote:
I doubt that. Look at the situation with the java tests where I'm the only
one who rewrites failing tests in c++. Most people just disable the test
that is failing and go on.
I just linked a bug that showed more 50 crash reports
On Wed, 2014-02-19 at 11:42 -0500, Kevin Hunter Kesling wrote:
I'm sorry to have ignited a discussion for which I wasn't looking. I
clearly don't have the authority to weigh in given my (lack of)
meritocratic wealth in the LibO community, so let me keep this simple:
I'm truly just trying
On Wed, 2014-02-19 at 10:45 -0600, James Michael DuPont wrote:
I have been doing a ton of work with pyuno at work and am interested
in anything to improve the code quality there.
So are we.
___
LibreOffice mailing list
On Wed, Feb 19, 2014 at 11:37:00AM -0500, Kohei Yoshida wrote:
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
On Wed, Feb 19, 2014 at 5:50 PM, Bjoern Michaelsen
bjoern.michael...@canonical.com wrote:
On Wed, Feb 19, 2014 at 05:20:19PM +0100, Markus Mohrhard wrote:
I doubt that. Look at the situation with the java tests where I'm the
only
one who rewrites failing tests in c++. Most people just
Hi Kevin,
On Wed, Feb 19, 2014 at 11:42:03AM -0500, Kevin Hunter Kesling wrote:
I'm sorry to have ignited a discussion for which I wasn't looking.
I think it was just a misunderstanding and tensions are still rising a bit high
because of the recent release. Things are clearing up now. So, no
On Wed, Feb 19, 2014 at 5:55 PM, Bjoern Michaelsen
bjoern.michael...@canonical.com wrote:
On Wed, Feb 19, 2014 at 11:37:00AM -0500, Kohei Yoshida wrote:
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
On Wed, Feb 19, 2014 at 11:37:00AM -0500, Kohei Yoshida wrote:
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?
Practical or not, this is daily reality for me. ;)
Best,
Bjoern
On Wed, Feb 19, 2014 at 05:57:26PM +0100, Markus Mohrhard wrote:
1) test core functionality with implementation details but that will rely
on implementation details and will bit rot if you don't execute them
2) test our stable API but then you should not try to avoid implementation
details
, meanwhile Python is one of the fastest growing
languages.
Regards,
-Keith
--
View this message in context:
http://nabble.documentfoundation.org/Re-Testing-Working-on-PyUNO-tp4097868p4097981.html
Sent from the Dev mailing list archive at Nabble.com
Hey Keith,
On Wed, Feb 19, 2014 at 6:47 PM, Keith Curtis keit...@gmail.com wrote:
Hi;
The C/C++ groups I worked in had all testers working in a scripting
language. Those who had the skills and interest to write in C/C++ moved to
product code. It was easy for developers to debug problems
Hi Markus,
Thanks for the explanation. I've recently been talking to lots of
younger programmers and so wanted to write a few words.
It is a conundrum to me why you have a quite large C++ team, but not
many people supplementing and polishing in Python, especially given
they should be easier to
25 matches
Mail list logo
