Konqueror CRASH 3.4.1 [The need for better quality control]
James Richard Tyrer
tyrerj at acm.org
Mon May 23 09:05:07 BST 2005
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
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.
More information about the kde-core-devel