* 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
