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
I hope that I reported this soon enough so that it will be fixed before
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
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