* G.W. Haywood wrote:
> Hi there,
>
> On Fri, 6 Nov 2009 Nathan Gibbs wrote:
>
>> Cut these guys some slack. They can't do everything.
>
> This isn't about cutting slack, or for that matter pointing fingers.
> It's about contributing. I'm contributing. Sometimes people don't
> want to hear what needs to be said. That can be painful all round,
> believe me.
>
I'm starting to see what you mean.
>> Thats the beauty of Open Source.
>
> Let's just say I'm familiar with the concept and leave it at that. We
> don't want you to get your foot completely stuck. :)
>
I appreciate that, it won't be the first time or the last.
Agree to disagree ?
:-)
>> ... report that its broken. If possible Where is it broken, why is
>> it borken, and how it might be fixed.
>
> That's exactly what I'm doing here. Unfortunately my message is not
> one which people often want to hear. They want to hear what a great
> job they do, not how they could improve on how they're doing things
> by doing things for which they really have little sympathy.
Right.
> There isn't some piece of code somewhere that has to be tweaked. If
> it were so it would be great, they'd just go off and tweak it and
> all would be well. But it isn't like that. The issue here is that if
> there is any system which is supposed to prevent problems of the
> sort that we see so often in releases of ClamAV, then demonstrably it
> isn't working.
>
I'll admin that the 0.94 and 0.95 releases have been a bit more
interesting than just install it and move on. The initial clamav 0.95
upgrade broke some internal code here. The EOL note for 0.94 seems to
indicate that after 4-15-2010 anything that isn't upgraded will blow.
Personally, ( switching feet here ) I don't fault the Clamav team for
these decisions, although I feel it is a little rough on the user base.
I feel that the code is improving, and these are just some things we
will have to deal with.
> My contention is that there is no system,
I'll disagree with you there. One man's chaos is another mans order.
I'm not missing your point that the "system" could improve.
> and that's what needs to be fixed. But as I don't employ the
> developers, all I can do is point to some of the benefits of using
> modern (i.e. developed in the past fifty years or so) quality
> systems.
Snip
> Quality systems can and do result in improvements of a couple of
> orders of magnitude in fault density in software (measured for
> example in coding errors per 1000 lines of code). The user's
> experience will inevitably improve as a result - and let's not forget
> that one coding error can easily cost several hours of the time of
> each of thousands of the code's users - but in addition, the
> developers will be able to get on with their developing instead of
> spending large chunks of time tracking down the faults which they
> themselves put there because they didn't have some kind of system.
>
Been there, done that, no fun.
> Obviously I don't claim that all errors can be eliminated, but I have
> seen the results of using and failing to use quality systems and the
> differences can be stunning.
Snip
Agreed.
> The cost to one company of ignoring a few simple quality procedures
> ... was ... loss of customer goodwill.
Which in open source is one thing you don't want to lose.
Snip
> It doesn't really matter what the product is, and despite what you're
> thinking right now it is _very_ relevant to software, if the software
> is built in anything like a modular fashion as probably it should be.
>
Agreed, its far less expensive to fix an error before release than after.
>
> But you don't have to implement the whole thing as an automated
> toolset, a lot of it can be paper-based or some other manual method
> such as just writing in a comment at the top of every function what
> the expected inputs and outputs are, then making sure (by inspection
> or by test procedures in the code itself, and preferably both) that
> those are indeed the things that happen in practice.
>
Eight.
> As I said in my first post, quality systems are fundamentally about
> documentation. We all know what a popular subject that is. :( One
> aspect of the documentation in this case would be writing down how to
> prevent these things from happening. That's the first problem. If
> you can't do that then you're in real trouble, it probably means that
> you don't know _why_ the things are happening. But at least now you
> know what the real problem is. It has little to do with the code. It
> will take time and a little effort, but once it's done, then all you
> have to do is what you wrote down you would do. That just takes
> discipline. Admittedly this is another relatively unpopular concept
> in the programming community. :)
>
You are SO RIGHT on that point. A massive benefit can be obtained by
documenting ( even informally ) what you are doing.
This precisely hits some of the issues around a recent bug I put into
the tracker. Whether they add the feature or not isn't important what is
there isn't documented very well. As i said in the bug report.
"Please consider documenting all of the Environment variables that are
set on the external events.
When I read the manual & don't find them, as far as I'm concerned they
don't exist."
<Note>
When I set up our network, I kept it all "in my head".
Did it that way until late 2005.
Started documenting basic stuff.
Increased the detail slowly over time.
Now I spend less time troubleshooting and more time trouble fixing or
doing more productive work.
<End Note>
Snip
> There are many more sources of information about software quality
> assurance on the Web, but the first step must be to recognize that
> there is a problem to be solved. When that is done, the developers
> are in a position to apply the techniques needed to solve it.
>
Agreed.
Seriously, you may want to rethink your style of approach.
I feel that I understand where you are coming from now, after lengthy
explanation.
I, possibly incorrectly, understood you first post to mean.
"Won't you stupid Clamav developers get it right already."
What I believe you meant was.
"The Clamav developers should design & consistently execute their QA
process."
I reserve the right to be wrong here (switching feet again).
Since the sourcefire acquisition, I've had higher expectations for
Clamav. Solution wise I don't feel I have been disappointed.
However, from my seat in the user base, I seriously wonder if they give
a care about the users.
--
Sincerely,
Nathan Gibbs
Systems Administrator
Christ Media
http://www.cmpublishers.com
_______________________________________________
Help us build a comprehensive ClamAV guide: visit
http://wiki.clamav.net
http://www.clamav.net/support/ml
(text/plain)
