Getting to 100 % succedding tests (for 2.9), or, simply dropping them all?

[Jaroslaw Staniek]

On 5 February 2015 at 07:11, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
[..]
> PROPOSAL B
>
> You are about to hit your Reply button hard after reading proposal A, because
> you actually prefer tests? Actually I do as well, and those people who spend
> the effort to write, review and maintain all those tests surely also did.

Thanks so much for taking these steps, Friedrich.

tl;dr of course B, our software is not a simple iPhone game for kittens... :)

I trust the social thing is a challenge to be addressed, and the
result maintained. It's up to app maintainers to convince writing
tests for new code[1], and Kexi has a lot to change in this regard.
Existence of tests in predicate.git (calligradb-next) demonstrated
it's cheap effort. We want to fight with regressions and in particular
part of Kexi's mission is to protect user's data from disappearing.

Regarding the currently failing tests, they are often not less
important than 'regular' bugs. For hard to solve defects if someone
feels it helps to emphasize a tasks to do reporting bugs for them (or
using todo.kde.org tasks) can be an option too. Mark as as release
blockers if needed.

BTW, My future idea related to framework-ify some libs is to have
tests and autotests as in known from the template [2] (Qt, KF5
standards).

[1] A mandatory 'tests' field on the review board or enforced commit
message field could be nice
[2] http://quickgit.kde.org/?p=kdeexamples.git&a=tree&f=framework-template

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek