[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Upstream bugs... (Qt)
From:       Parker Coates <parker.coates () gmail ! com>
Date:       2009-11-27 13:33:58
Message-ID: 85d347350911270533i7d76a539sa86f03c2e71ddc44 () mail ! gmail ! com
[Download RAW message or body]

On Thu, Nov 26, 2009 at 13:54, Thiago Macieira wrote:
> Em Quinta-feira 26. Novembro 2009, Ã s 18.50.11, Parker Coates escreveu:
>> On Thu, Nov 26, 2009 at 12:12, Alexis Ménard wrote:
>> > On Thu, Nov 26, 2009 at 4:46 PM, Dmitry Suzdalev wrote:
>> >> On Thursday 26 November 2009 18:35:23 John Tapsell wrote:
>> >> > Whoever writes the test case of course :-)
>> >>
>> >> By the way is the minimal test case really required?
>> >
>> > It's not mandatory, but it is good for Qt Developers. It's more
>> > efficient, we don't have to checkout the part of KDE (mess up our dev
>> > machine with development version of KDE) that we need to reproduce and
>> > fix the bug. Most important is Qt Devs that don't have KDE/Linux, they
>> > can't help without test case, they don't have a proper KDE set up.
>>
>> How do you feel about testcases in languages other than C++? Obviously
>> if the bug is related to pointers or crashes or other low level stuff,
>> C++ is the only option that makes sense, but for simple functionality
>> issues ("This widget does <something weird> when I do <action>.")
>> whipping up an example in PyQt is only about a quarter of the effort.
>
> We don't make PyQt, so we cannot accept bugs against it or using it as a
> testcase. Sorry.

Sorry, I should have been clearer. Of course you don't accept bugs
against PyQt. I was talking about the case where the problem has shown
up in a real C++ app, but the code in question is too complicated to
realistically hack down to a simple case. If starting from scratch, a
dynamic language is usually much more productive for small programs.
But if you don't accept them that's fine.

> A PyQt testcase is only slightly better than describing the problem in plain
> English. It's still way short from a proper C++ testcase which we can just
> plug into the automatic test system.

Okay, this makes it clear that I don't really know what a testcase is
supposed to be. I had assumed they were just examples to demonstrate
that the issue exists and maybe show a couple of workarounds. But
obviously they need to be more than that to plug them into an
automatic system. Are they supposed to be actual QTest tests? Are
there special rules for writing them? How does the automatic test
system work? If I report an intermittent rendering issue in QGV, can I
realistically write a testcase? Is all of this documented somewhere
and am I annoying you with questions for no good reason?

Inquisitively yours,

Parker
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]