Konqueror CRASH 3.4.1 [The need for better quality control]

[James Richard Tyrer]

Aaron J. Seigo wrote:
> On Saturday 21 May 2005 04:58, James Richard Tyrer wrote:
> 
>> The release should have been more widely publicised.  Would it be
> 
> 
> it was pretty well announced:  kde-cvs-announce at kde.org, 
> kde-core-devel at kde.org, kde-i18n-doc at kde.org, kde-packager at kde.org
> 
> it wasn't kept quiet.
> 
> 
>> When I learned of the release, I moved isolating the problem and
>> filing a report to the top of my to do list.
> 
> 
> great =)
> 
> 
>> I have previously stated that we need to quit using the "old
>> Detroit" method of quality control.  The "old Detroit" method is
>> that first you build something, then you inspect it, and, LAST, you
>> try to fix what is wrong with it.  The Demming method (TQM) is that
>> you build it right (to start with).
> 
> 
> lectures and rediculous expectations are not "the answer".

Please excuse my professorial tone.  I realize that it tend to be off
putting, but that is my personality and am probably too old to change 
it.  I am just relating what I have been taught.  It remains my belief 
that there must be a more efficient way to this than bug hutting after 
the fact.

Unrealistic expectations: People have accused Bjorne Stroustrup of 
suggesting that coders learn to 'walk on water' in response to some of 
his suggestions about quality. :-)

> here's something that _might_ work, however:
> 
> track the current stable branch. filter the kde-cvs email list for
> all branch/ commits, test each of those commits as they occur. then
> it won't be a "wait until we near release" to do this testing.

This isn't quite what I meant.  It is best if the developer adding the 
code can do the testing because he knows the code best.  But, if this 
isn't possible, he can pass the job of QM down to an assistant or pool 
of assistants or the maintainer can to it or have an assistant do it. 
OTOH, what you suggest might work.

> this would take a few people, i imagine, but if you lead with example
> and recruit others on, say, kde-quality and elsewhere to join you in
> those efforts (leading by example would be key) i'm sure you could
> round up the necessary manpower to help with this issue.
> 
If this actually works, we should save time in the long run.  The 
developer spends a little time testing when he makes a change but he, or 
others, saves a lot of time because they don't have to go bug hunting 
later.  I can't say for sure if it would work for KDE, I am only 
relating the theory.  Many industries have adopted Demming's ideas so 
they must have some merit.

-- 
JRT