Konqueror CRASH 3.4.1 [The need for better quality control]

James Richard Tyrer tyrerj at acm.org
Sat May 21 23:58:48 BST 2005

It appears that we still need to find a way to achieve better quality 

Please see:


I hope that I reported this soon enough so that it will be fixed before 
the release.


The release should have been more widely publicised.  Would it be 
possible to at least post such an announcement to 'kde-devel'.  I would 
suggest: 'kde', 'kde-linux', & 'kde-quality' as well.  Keeping the 
release quiet doesn't serve any good purpose.

When I learned of the release, I moved isolating the problem and filing 
a report to the top of my to do list.

As I have said before, any serious regression should be considered to be 
a show stopper, and BugZilla should have some way to indicate a 
regression.  I presume that a Konqueror crash is serious.  And this is a 

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).  Just exactly how this will apply in this case depends on 
exactly what the problem is.  I don't know if the problem is with Ark or 
with Konqueror.

But, to explain what I am talking about, I will assume that the problem 
is with Ark.  In that case, some change would have been made to the Ark 
code.  I learned TQM so what I do when I am making changes to code is 
that I make some changes, I build it, then I open the app and see how it 
works -- yes this is the basic TQM method.  I don't know how most KDE 
developers do it, but I recommend the method which I learned.

This should be a little more rigorous in the case of the maintainer of 
Ark.  There should be a set of regression tests.  The above bug is not 
obscure -- it would have been caught by the most basic set of Ark 
regression tests.  So, after the changes to code are completed the 
regression tests should be run BEFORE the code is committed (at least 
before it is committed to a branch).

If the problem is not with Ark, then the issue is not as simple. 
However, it would have still been caught if the Ark maintainer had run 
the set of Ark regression tests as soon as the release was announced.

Implicit in the above is that the procedure for a release should include 
every maintainer signing off on it.

Developers will say that they don't have time to do this.  But, that 
would be wrong.  Industry has adopted Demming's methods because they 
save money.  I presume that they would also save us time.

I also note that if 3.4.1 goes out the door without this crash being 
fixed, the problem is more serious.  The problem, which has occurred 
more than once with previous 3.x.y releases, would then be that certain 
developers are not sufficiently concerned with the quality of the 
product.  If we expect for KDE to be a commercial success, such an 
attitude MUST be changed if it hasn't already changed.


More information about the kde-core-devel mailing list