Konqueror CRASH 3.4.1 [The need for better quality control]

[James Richard Tyrer]

Stephan Kulow wrote:
> On Sunday 22 May 2005 00:58, James Richard Tyrer wrote:
> 
> 
>> 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 regression.
> 
> This is not a regression. It has been reported to KDE 3.4.0 about a 
> dozen times.

I don't think that I had the problem with 3.4.0 (Release) but rather it
seemed to start occurring in the 3.4 BRANCH some weeks after the 
release.  But, I can't say for certain.

This (and the rest of that bug) does indicate that it was a regression:

http://bugs.kde.org/show_bug.cgi?id=103795#c39

That is, it used to work and then something was added that broke
something -- a regression.

The backport was dated:  2005-05-17 19:57 which leaves me wondering why
my SVN tree was out dated despite the fact that I update at least
KDElibs and KDEBase every day.

> 
> But once again: you're welcome to spend as much time as you like 
> testing the 3.4 branch using all kind of test cases.

As I said, my comments about TQM are based on there being some related 
and simple things to test.  Since this was an odd bug, they wouldn't 
have worked there, but this doesn't mean that they are not valid.

> But we just don't have enough man power to wait for anything like
> that.

Please try to understand my concept in more depth.  My idea isn't about 
someone else doing the testing (unless that person is an assistant to 
the maintainer).  The idea is that when changes are made that then 
testing should immediately follow in response to the changes.

I have no case studies for KDE, but the theory is that this would take 
less time than waiting for a bug to be reported and then taking a lot of 
time searching for the cause of it.

So, for example in this case, either the person that changed 
kdelibs/kio/kio/kdirlister.cpp should have done some testing or the 
maintainer should have posted the job to an assistant to do.  Perhaps in 
this case it wouldn't have worked, but in many cases it would.

To be clear, what I am saying is that doing some testing to prevent 
regression bugs from getting into the code in the first place is easier 
than bug hunting later.  And if you read bug 103795 you can see that 
finding this wasn't simple.

-- 
JRT