Bug 103795

[Aaron J. Seigo]

On Monday 23 May 2005 10:13, James Richard Tyrer wrote:
> (perhaps to the point of being boring).  If my blogs seem vehement, it
> is because I do care about this (is that bad).

caring is not bad, being rude is not healthy for a community's wellbeing.

btw, blogging happens on the web. blog is a mutated version of "web log". =) 
on an email list, where it gets pushed out to everyone subscribed, we usually  
call it "ranting". =)

> The major presumption appears to be that we don't have enough volunteers
> to do the *extra* work to implement the ideas I have advocated.

it's not about _extra_ work, it's about imposing a different set of work. 
that's the unrealistic part given hard reality. you need to find people, 
preferably starting with yourself, to take up that different set of work. if 
it improves efficiency, everyone wins.

> So, try to understand that if sufficient testing had been done at the
> time this minor change was made to: kdelibs/kio/kio/kdirlister.cpp to
> prevent the introduction of the bug into the code base that all of the
> time spent bug hunting and handling the bug reports on BugZilla would be
> saved.  This seems like a simple concept.  This would not have taken
> less work, it would have taken less work.

yes, if we were perfect we'd have fewer corrections to fix.
if we had 100% code coverage with our tests, we could identify most of our 
coding errors quickly. (note that test coverage for GUI's is notoriously 
unsolved)
if we had people running those tests for each changeset, we would catch the 
bulk of errors.

as you can see, this is new work. it may result in an overall greater 
efficiency, but it is new process. since we won't become magically perfect, 
we could use people who are writing test suites and people who are running 
them. who is going to do that?

> It has been suggested that I should recruit people to test other peoples
> code.  This is not about testing other peoples code, it is about testing
> you own code.  You can work in a group, but that probably isn't as
> efficient.

yes, it is more efficient, for many reasons. beyond parallelization, look up 
"pair programming techniques" for some other reasons. but beyond efficiency, 
there's REALITY to be faced. we can not and will not force everyone to follow 
some arbitrary development system. that means we need to augment that 
development system. 

i'd go so far sa to say that writing and running tests (and then triaging that 
information) is something that can be done by far more people than the actual 
original development. so from a resource expenditure point of view, it would 
be great to spend that wider skill pool on tasks appropriate for the 
abilities.

> It is correctly stated that BugZilla is overloaded and that we don't
> have enough people to maintain it.  This is correct.  I am suggesting
> that we go at this from a different direction.  If we can prevent the
> introduction of bugs into the code base, we wouldn't have a many reports
> on BugZilla.

and yet the amount of effort required is still there. Bugzilla is an 
interesting data point because it's EASIER than what you suggest and already 
has buy-in, yet doesn't work because many people who claim to care about 
KDE's quality don't do much about it.

> It was also suggested that I should lead by example.  I think that this
> is a good method which I try to practice.  I don't exactly know how to
> do that in this case since I sit alone at my computer and use the
> methods which I advocate. 

why not pick an area of KDE that has poor test suite coverage and write tests?
 
> So, if there is anyone out there with an open mind (that does not
> express the usual reactionary response to a new idea) that would like to
> discuss this, please post your comments.  I also ask that those of you
> with a closed mind set please not take my word for anything.  Instead,

just because i don't agree with some of what you say does not mean i don't 
have an open mind. i truly hope that isn't what you were trying to get at 
here.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-quality/attachments/20050523/b9921931/attachment.pgp