[kde-quality] Re: Massive Konqueror Regression

[James J. Baker]

I loudly applaud Mr. Woelz's patient, objective, lucid, and informative
replies (defenses?) to Mr. van Hoose's chronic and, in my opinion, abrasive
and insulting posts. Mr. Woelz' exemplary disposition shows the character of
people who spend considerable time and effort to improve access to digital
media when they might not otherwise be able to afford it.
    Mr. Woelz: I appreciate your fine work and commitment to open source.
    Nice job. 
    Jay Bee

on 8/18/05 9:14 AM, Carlos Leonhard Woelz at carloswoelz at imap-mail.com
wrote:

> 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
> _______________________________________________
> kde-quality mailing list
> kde-quality at kde.org
> https://mail.kde.org/mailman/listinfo/kde-quality
>