[kde-quality] Re: Massive Konqueror Regression

[Carlos Leonhard Woelz]

On Thu, 18 Aug 2005 09:58:38 -0400, "David van Hoose"
<david.vanhoose at comcast.net> said:
> 
> Functionality CAN be tested with thorough regression tests.
Do you really think we don't know that?

> I keep hearing:
>    * KHTML isn't buggy, you're an idiot.
KHTML isn't "buggy". It has bugs, which is different from being "buggy".
It is unpolite to call other people (unpaid) work buggy without
presenting strong evidence.

>    * KDE has great regression tests even though the are numerous
>      regressions.
No. KHTML has great regression tests. KDE in general lacks automated
regression tests.

>    * KDE needs more people in order to release a decent desktop.
You are really being offensive now. KDE is a "decent" desktop.

> Notice how everyone is missing the point?
What point? You are saying basically that KDE releases have regressions,
and that is "unacceptable"? We get it, and we are always trying to
improve KDE.

What you don't want to see is that we *agree* with you that KDE could be
a better product with more testing. We even said that one of the
problems is that people do not jump into the beta process as we would
like, making the point zero releases a bit more buggy that what we would
like.

You also don't want to understand that we don't have any way to *force*
people to do what they do not want, they are volunteers, and we
therefore don't have an army of developers at our disposal. The choice
is not between "stop creating features" and "making it bug free", as
people seem to believe. The process of stopping the new development
would probably kill any open source project, as you will lose most of
your developers this way.

If you are not providing a new solution to the problem, or offering your
help, we are wasting our time on this thread. I, for one, think a lot
about how to improve the situation, but I since I can't find real
solutions, I don't start flaming volunteer developers.

If you want to discuss a real solution, let me give you some basics:

1) KDE is a volunteer effort, which you get for free

2) KDE progress depends mainly on its developer base. Obviously,
there is a relationship between the user base and the developer
base. In open source, things work this way:

Unpaid developers --> New product --> Users (and developers)
     ^                                             | 
     |________________New Developers ______________|

Do you see that the key for advancing a project is to attract new
developers?

In the closed source world, the user's money is the key:

Investor --> Paid developers --> Product --> users
     ^                                         | 
     |_________________ Money _________________|


So you see that the main link here is money, instead of developers? And
that you can't work in the closed source model without the money?

In other words, the user can't be the main driver of the development
process and pay nothing at the same time. The driver of the development
in the open source world are motivated developers, not users. I don't
want to play down the importance of the user base in recruiting new
developers. I just want you to understand the importance of creating a
motivating environment for volunteer developers.

2) Testing is a time consuming, boring process

3) Basic testing *is* in most performed by the developers. It is
required by the guidelines

4) Automated testing is done in some parts of KDE, but not all. This
should be improved, but as always, we can't tell people what to do.

5) Comprehensive testing is an excellent task for users, as it relieves
the burden for the (unpaid, volunteer) developers. This is normal in
open source software (release often, release early).

Unless you can offer money, man power or concrete solutions to help
solving this problem, it is useless to continue discussing this thread.

Please take your time to think about the challenges of quality control
on an open source, volunteer effort, mail me in private if you want to
discuss this further. If we reach some new conclusions, then we can post
them to the list.

Cheers,

Carlos Woelz